Re: [REGRESSION][BISECTED] Crash with Bad page state for FUSE/Flatpak related applications since v6.13

["Mantas Mikulėnas" <grawity@gmail.com>]

On 2025-02-08 2:02, Bernd Schubert wrote:
> 
> 
> On 2/7/25 19:40, Joanne Koong wrote:
>> On Fri, Feb 7, 2025 at 3:16 AM Bernd Schubert <bernd@bsbernd.com> wrote:
>>>
>>>
>>>
>>> On 2/7/25 11:55, Vlastimil Babka wrote:
>>>> On 2/7/25 11:43, Miklos Szeredi wrote:
>>>>> On Fri, 7 Feb 2025 at 11:25, Vlastimil Babka <vbabka@suse.cz> wrote:
>>>>>
>>>>>> Could be a use-after free of the page, which sets PG_lru again. The list
>>>>>> corruptions in __rmqueue_pcplist also suggest some page manipulation after
>>>>>> free. The -1 refcount suggests somebody was using the page while it was
>>>>>> freed due to refcount dropping to 0 and then did a put_page()?
>>>>>
>>>>> Can you suggest any debug options that could help pinpoint the offender?
>>>>
>>>> CONFIG_DEBUG_VM enables a check in put_page_testzero() that would catch the
>>>> underflow (modulo a tiny race window where it wouldn't). Worth trying.
>>>
>>> I typically run all of my tests with these options enabled
>>>
>>> https://github.com/bsbernd/tiny-qemu-virtio-kernel-config
>>>
>>>
>>> If Christian or Mantas could tell me what I need to install and run, I
>>> could probably quickly give it a try.
>>>
>>
>> Copying/pasting from [1], these are the repro steps that's listed:
>>
>> 1) Install Bottles: flatpak install flathub com.usebottles.bottles
>> 2) Open Bottles and create a bottle
>> 3) In a terminal open the kernel log using dmesg/journalctl in follow mode
>> 4) Once the bottle has been initialized, open it, select "Run
>> Executable" and point it at any Windows executable
>> Note that at that same moment a BUG: Bad page state in process fuse
>> mainloop error message will appear and the system will become
>> unresponsive (keyboard and mouse might still work but you'll be unable
>> to actually do anything, open or close any application, or even reboot
>> or shutdown; you are able to ping the device and initiate an SSH
>> connection but all it does is just display the banner)
>>
> 
> Thanks Joanne! Hmm, I found "wmplayer" in a c drive, but there doesn't
> happen much
> 
>     5241 pts/0    Ss     0:00 -bash
>     5317 pts/1    S+     0:00 /home/bernd/.var/app/com.usebottles.bottles/data/bottles/runners/soda-9.0-1/bin/wi
>     5319 ?        Ss     0:01 /home/bernd/.var/app/com.usebottles.bottles/data/bottles/runners/soda-9.0-1/bin/wi
>     5321 pts/1    S+     0:01 C:\windows\system32\wineboot.exe --init
>     5345 ?        Ssl    0:01 C:\windows\system32\services.exe
>     5348 ?        Ssl    0:00 C:\windows\system32\winedevice.exe
>     5359 ?        Ssl    0:01 C:\windows\system32\winedevice.exe
>     5360 ?        I      0:00 [kworker/u130:0-rpciod]
> 
> It runs it, but no system issue. I had also tried "Obfuscate", but didn't
> manage to feed it a file - it runs in the sandbox and no access to
> my $HOME.

That is the point -- the bug is triggered by using Flatpak's FUSE-based 
"sandboxed file access" mechanism. The sandboxed app is supposed to ask 
'xdg-desktop-portal' to give it some file, which then lets you select a 
file and exposes it through its FUSE mount inside the sandbox (which is 
also visible at /run/user/1000/doc outside the sandbox).

So the specific app probably doesn't matter, as long as it *is* in fact 
sandboxed without direct access to your $HOME, and as long as you have 
xdg-desktop-portal installed.

I had suggested "Obfuscate" both because it was what originally led to 
the crash in my case, and because it's a fairly basic app where opening 
a file happens to be step 1 of its usual workflow so it's quick to test. 
Other similar ones might be:
https://flathub.org/apps/com.belmoussaoui.ashpd.demo ("File chooser")

The actual FUSE code is at:
https://github.com/flatpak/xdg-desktop-portal/blob/main/document-portal/document-portal-fuse.c#L2041

I guess any other filesystem that relies on libfuse's direct splice 
support would also be able to repro? I don't know if there are any.