[Bug]: Linux guest aborts with Guru Meditation 1155 (VINF_EM_TRIPLE_FAULT) shortly after a guestmemoryballoon request

[n6koma7a]

Version

7.2.16 r174877

Host OS Type

Windows

Host OS name + version

Windows 11, build 10.0.26200.9445

Host Architecture

x86 (AMD64)

Guest OS Type

Linux

Guest Architecture

x86 (64-bit)

Guest OS name + version

Fedora 44, kernel 7.1.13-200.fc44.x86_64 (root on btrfs/LUKS, NVMe controller, 10240 MB RAM assigned)

Component

VMM / VM control

What happened?

A running Linux guest was aborted by a Guru Meditation triple fault ~90 s after a VBoxManage controlvm ... guestmemoryballoon 1024 request. The resulting power-off left the guest's btrfs metadata corrupted: the guest could no longer mount its root (bad tree block start on both mirrors during log-tree replay, Transaction aborted, open_ctree failed: -5) and needed btrfs rescue/repair before it would boot again.

Timeline (host log timestamps; session opened 20:58:38Z):

• Guest healthy throughout: ~1.5 GB free / ~7.5 GB available of 10240 MB, Guest/RAM/Usage/* metrics reporting, no OOM-killer, no hung-task or reclaim-stall warnings, zram swap 0 B used.
• VBoxManage controlvm iris guestmemoryballoon 1024 issued.
• The guest's last log entry follows almost immediately; the guest then goes silent.
• VBoxManage controlvm iris guestmemoryballoon 0 issued ~20 s later.
• ~90 s after the inflate:

00:12:38.930041 Changing the VM state from 'RUNNING' to 'GURU_MEDITATION'
00:12:38.930090 Console: Machine state changed to 'Stuck'
00:12:38.930413 !!         VCPU5: Guru Meditation 1155 (VINF_EM_TRIPLE_FAULT)
00:12:38.930422 !! Skipping ring-0 registers and stack, rcErr=VINF_EM_TRIPLE_FAULT
00:12:38.932843 CPUM0: Disas -> VERR_PAGE_TABLE_NOT_PRESENT
             cr3=0000000094556000  cr2=00007f6b8099d000
             rcLastExitToR3 = VINF_EM_TRIPLE_FAULT
00:13:30.358973 GUI: User requested to power VM off on Guru Meditation.

• Balloon state at abort: MemBalloonSize 0, /Devices/VMMDev/BalloonChunks 0 count, /GMM/VM/cBalloonedPages 0 pages, /GMM/VM/cReqActuallyBalloonedPages 0 pages, /GMM/VM/fBallooningEnabled false. Neither the host log nor the guest log contains any other balloon-related line, so there is no positive evidence the inflate was ever applied — consistent with the deflate having completed first.

Additional context:

• The guest's vboxguest kernel module is the distribution (in-tree) one, so the host sees VMMDev: Guest Additions information report: Version 6.0.0 r127566 '6.0.0' while the Additions userland is 7.2.16 r174877 (related: [Req]: VirtualBox guest kmod join to the Linux mainline #444). Question: is guestmemoryballoon expected to work in this configuration, and does the VMM validate a balloon request against the Additions version it has been told?
• The log shows VMSVGA display activity shortly before the abort (VMSVGA: Using HW accelerated screen 0, Display::i_handleDisplayResize ... w=1920 h=1102) at 00:10:47 and 00:12:09. Listing it for completeness, since a display-related trigger cannot be excluded from the log alone.

How can we reproduce this?

Not retried deliberately: the first occurrence destroyed the guest filesystem and the VM had no snapshot. A safe reproduction, if wanted: snapshot the VM first, then run VBoxManage controlvm <vm> guestmemoryballoon 256 against a Linux guest using the in-tree vboxguest module and watch for the VM entering GURU_MEDITATION with VINF_EM_TRIPLE_FAULT.

Did you upload all of your necessary log files, screenshots, etc.?

• Yes, I've uploaded all pertinent files to this issue.

Logs: https://gist.github.com/n6koma7a/6989578af4bdb95edad2993709bb859d

(the session that aborted, plus an earlier failed startup from the same hour; Windows username sanitised to <user>)