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@xxxxxxxxxxx> 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@xxxxxxx> 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.
