[Bug 2167772] Re: vboxsf: endless write loop and data corruption on short copy

** Description changed: - [Summary] - Writing to a VirtualBox shared folder (vboxsf) from pages that have not been - faulted in makes the in-kernel vboxsf driver loop forever: the target file - keeps growing with zeroed data until the disk is full, the writing process - only dies on SIGKILL, and the log fills up with + SRU Justification: + [ Impact ] + + In the in-kernel VirtualBox shared folder driver (fs/vboxsf), writing to + a file from memory pages that have not been faulted into the process + page table causes the write path to enter an infinite loop. + + The destination file continuously grows with zeroes until the filesystem runs out of space, the writing process hangs permanently in kernel space (can only be killed with SIGKILL), and the kernel log is flooded with: WARNING: lib/iov_iter.c:624 at iov_iter_revert+0x1fc/0x270 - In my case ~16 GB of logs were written before the guest ran out of - space. + Furthermore, if the target page/folio is already marked uptodate in the + page cache, un-copied ranges are not zeroed, which causes vboxsf to + write stale page cache contents to the host, resulting in silent data + corruption. - [Root cause] - vboxsf_write_end() ignores "copied": it writes the full requested length to - the host and returns that length even when copied == 0, so - generic_perform_write() never faults the source pages in, advances pos and - loops forever. The same accounting bug can silently corrupt data when the - folio is already uptodate. + This condition is reliably triggered by applications that write directly + from an mmap of another file or from shared memory without touching the + pages first. For example, virtiofsd (used in nested virtualisation + workloads, container runtimes, and developer sandboxes) operates in this + manner and triggers the failure immediately. - [Upstream] - Patch submitted to the vboxsf maintainer and linux-fsdevel on 2026-09-19: - https://lore.kernel.org/linux-fsdevel/20260919174136.3325-1-k.shiomi@techhowto.blog/ + [ Fix ] - A DKMS package with the patch (and a guard that refuses to mount shared - folders unless the patched module is loaded) is available at - https://github.com/kentaro-shiomi/virtualbox-vboxsf-endless-write-loop-fix + In fs/vboxsf/file.c:vboxsf_write_end(), the driver previously initialised its byte counter with the requested length rather than the actually copied bytes: + u32 nwritten = len; - [Trigger] - Programs that write straight from an mmap of another file or from shared - memory without reading it first. virtiofsd does exactly this, so running a - nested VM whose working directory lives on a vboxsf mount hits it immediately. - Ordinary applications write from buffers they have just filled and are not - affected. + When a short copy occurs (copied < len, or copied == 0 due to an un- + faulted page), the driver incorrectly wrote 'len' bytes to the host and + returned 'len' to the VFS write loop. As a result, + generic_perform_write() never invoked fault_in_iov_iter_readable(), + advanced the file position by 'len' without advancing the user iterator, + and looped endlessly. - [Environment] - Ubuntu 26.04.1, kernel 7.0.0-31-generic, guest of VirtualBox 7.2.16 on a - Windows 11 host. The faulty code is identical in Linux v7.0 and in master as - of 2026-09. + The fix applies two changes: + 1. Initialise nwritten with the actually copied byte count: + u32 nwritten = copied; + 2. If nothing was copied (copied == 0), immediately exit via 'goto out' without calling vboxsf_write(), returning 0 to VFS. This allows generic_perform_write() to fall back to faulting in the source pages and retrying cleanly. + + [ Test Plan ] + + A minimal test using Python writes from an un-faulted mmap buffer into a + vboxsf mount: + + 1. Mount a VirtualBox shared folder: + sudo mount -t vboxsf shared_folder /mnt/shared + + 2. Run the reproducer: + python3 -c ' + import mmap, os + with open("/tmp/src.bin", "wb") as f: + f.write(b"A" * 65536) + with open("/tmp/src.bin", "rb") as f: + mm = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) + with open("/mnt/shared/test.bin", "wb") as out: + out.write(mm[:4096]) + print("Written:", os.path.getsize("/mnt/shared/test.bin")) + ' + + Verification criteria: + - Unpatched kernel: + The process hangs indefinitely. The file /mnt/shared/test.bin expands rapidly with zeroes until disk space is exhausted. dmesg shows repeated "WARNING: lib/iov_iter.c:624 at iov_iter_revert". + - Patched kernel: + The process finishes immediately with exit code 0. /mnt/shared/test.bin has exactly 4096 bytes containing the character 'A'. dmesg reports 0 warnings. + + [ Where problems could occur ] + + The change is strictly isolated to the write_end handler in + fs/vboxsf/file.c. + + In the standard case where copied == len, behavior is completely + identical. In the case where copied < len or copied == 0, the driver now + accurately conforms to the VFS address_space_operations contract by + reporting actual progress instead of fabricating a successful write. + + Potential regression risk is very low. If any side effects were to + occur, they would be strictly confined to writes on vboxsf mount points + and would not impact other filesystems or core kernel memory management. + + [ Other Info ] + + The patch was submitted upstream to linux-fsdevel and the vboxsf maintainer on 2026-09-19. + The underlying logic defect (u32 nwritten = len) has existed since vboxsf was merged in kernel 5.6. Consequently, this fix is required across all supported Ubuntu LTS releases: + - Resolute (7.0 kernel, folio-based) + - Noble (6.8 kernel, page-based) + - Jammy (5.15 kernel, page-based) + Clean patches for both the modern folio interface and stable page interface have been prepared and verified against Ubuntu kernel trees. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2167772 Title: vboxsf: endless write loop and data corruption on short copy Status in linux package in Ubuntu: New Bug description: SRU Justification: [ Impact ] In the in-kernel VirtualBox shared folder driver (fs/vboxsf), writing to a file from memory pages that have not been faulted into the process page table causes the write path to enter an infinite loop. The destination file continuously grows with zeroes until the filesystem runs out of space, the writing process hangs permanently in kernel space (can only be killed with SIGKILL), and the kernel log is flooded with: WARNING: lib/iov_iter.c:624 at iov_iter_revert+0x1fc/0x270 Furthermore, if the target page/folio is already marked uptodate in the page cache, un-copied ranges are not zeroed, which causes vboxsf to write stale page cache contents to the host, resulting in silent data corruption. This condition is reliably triggered by applications that write directly from an mmap of another file or from shared memory without touching the pages first. For example, virtiofsd (used in nested virtualisation workloads, container runtimes, and developer sandboxes) operates in this manner and triggers the failure immediately. [ Fix ] In fs/vboxsf/file.c:vboxsf_write_end(), the driver previously initialised its byte counter with the requested length rather than the actually copied bytes: u32 nwritten = len; When a short copy occurs (copied < len, or copied == 0 due to an un- faulted page), the driver incorrectly wrote 'len' bytes to the host and returned 'len' to the VFS write loop. As a result, generic_perform_write() never invoked fault_in_iov_iter_readable(), advanced the file position by 'len' without advancing the user iterator, and looped endlessly. The fix applies two changes: 1. Initialise nwritten with the actually copied byte count: u32 nwritten = copied; 2. If nothing was copied (copied == 0), immediately exit via 'goto out' without calling vboxsf_write(), returning 0 to VFS. This allows generic_perform_write() to fall back to faulting in the source pages and retrying cleanly. [ Test Plan ] A minimal test using Python writes from an un-faulted mmap buffer into a vboxsf mount: 1. Mount a VirtualBox shared folder: sudo mount -t vboxsf shared_folder /mnt/shared 2. Run the reproducer: python3 -c ' import mmap, os with open("/tmp/src.bin", "wb") as f: f.write(b"A" * 65536) with open("/tmp/src.bin", "rb") as f: mm = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) with open("/mnt/shared/test.bin", "wb") as out: out.write(mm[:4096]) print("Written:", os.path.getsize("/mnt/shared/test.bin")) ' Verification criteria: - Unpatched kernel: The process hangs indefinitely. The file /mnt/shared/test.bin expands rapidly with zeroes until disk space is exhausted. dmesg shows repeated "WARNING: lib/iov_iter.c:624 at iov_iter_revert". - Patched kernel: The process finishes immediately with exit code 0. /mnt/shared/test.bin has exactly 4096 bytes containing the character 'A'. dmesg reports 0 warnings. [ Where problems could occur ] The change is strictly isolated to the write_end handler in fs/vboxsf/file.c. In the standard case where copied == len, behavior is completely identical. In the case where copied < len or copied == 0, the driver now accurately conforms to the VFS address_space_operations contract by reporting actual progress instead of fabricating a successful write. Potential regression risk is very low. If any side effects were to occur, they would be strictly confined to writes on vboxsf mount points and would not impact other filesystems or core kernel memory management. [ Other Info ] The patch was submitted upstream to linux-fsdevel and the vboxsf maintainer on 2026-09-19. The underlying logic defect (u32 nwritten = len) has existed since vboxsf was merged in kernel 5.6. Consequently, this fix is required across all supported Ubuntu LTS releases: - Resolute (7.0 kernel, folio-based) - Noble (6.8 kernel, page-based) - Jammy (5.15 kernel, page-based) Clean patches for both the modern folio interface and stable page interface have been prepared and verified against Ubuntu kernel trees. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167772/+subscriptions

[Bug 2167785] [NEW] ethernet connection breaks after wakeup

Public bug reported: Intel I226-V Ethernet fails after suspend/resume on Ubuntu 26.04. Hardware: Intel I226-V [8086:125c], rev 06 Driver: igc Kernel: 7.0.0-31-generic Steps: 1. Ethernet works normally. 2. Suspend system. 3. Resume. 4. eno2 becomes unavailable and Ethernet does not reconnect. 5. Reloading the igc module restores the interface: sudo modprobe -r igc sudo modprobe igc After reload, carrier returns, NetworkManager obtains DHCP address 192.168.1.10, and Ethernet works normally. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-31-generic 7.0.0-31.31 ProcVersionSignature: Ubuntu 7.0.0-31.31-generic 7.0.14 Uname: Linux 7.0.0-31-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun Sep 20 09:57:59 2026 InstallationDate: Installed on 2026-09-18 (2 days ago) InstallationMedia: Ubuntu 26.04.1 LTS "Resolute Raccoon" - Release amd64 (20260826) IwDevWlo1Link: Not connected. MachineType: ASUS System Product Name ProcFB: 0 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-31-generic root=UUID=6f7598f7-82dc-4ea2-9204-aa3d9d9687ee ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/28/2023 dmi.bios.release: 4.4 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 0404 dmi.board.asset.tag: Default string dmi.board.name: ROG STRIX Z790-F GAMING WIFI II dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev 1.xx dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr0404:bd09/28/2023:br4.4:svnASUS:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnROGSTRIXZ790-FGAMINGWIFIII:rvrRev1.xx:cvnDefaultstring:ct3:cvrDefaultstring:skuSKU:pfaTobefilledbyO.E.M.: dmi.product.family: To be filled by O.E.M. dmi.product.name: System Product Name dmi.product.sku: SKU dmi.product.version: System Version dmi.sys.vendor: ASUS ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug resolute wayland-session -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2167785 Title: ethernet connection breaks after wakeup Status in linux package in Ubuntu: New Bug description: Intel I226-V Ethernet fails after suspend/resume on Ubuntu 26.04. Hardware: Intel I226-V [8086:125c], rev 06 Driver: igc Kernel: 7.0.0-31-generic Steps: 1. Ethernet works normally. 2. Suspend system. 3. Resume. 4. eno2 becomes unavailable and Ethernet does not reconnect. 5. Reloading the igc module restores the interface: sudo modprobe -r igc sudo modprobe igc After reload, carrier returns, NetworkManager obtains DHCP address 192.168.1.10, and Ethernet works normally. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-31-generic 7.0.0-31.31 ProcVersionSignature: Ubuntu 7.0.0-31.31-generic 7.0.14 Uname: Linux 7.0.0-31-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun Sep 20 09:57:59 2026 InstallationDate: Installed on 2026-09-18 (2 days ago) InstallationMedia: Ubuntu 26.04.1 LTS "Resolute Raccoon" - Release amd64 (20260826) IwDevWlo1Link: Not connected. MachineType: ASUS System Product Name ProcFB: 0 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-31-generic root=UUID=6f7598f7-82dc-4ea2-9204-aa3d9d9687ee ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/28/2023 dmi.bios.release: 4.4 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 0404 dmi.board.asset.tag: Default string dmi.board.name: ROG STRIX Z790-F GAMING WIFI II dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev 1.xx dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr0404:bd09/28/2023:br4.4:svnASUS:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnROGSTRIXZ790-FGAMINGWIFIII:rvrRev1.xx:cvnDefaultstring:ct3:cvrDefaultstring:skuSKU:pfaTobefilledbyO.E.M.: dmi.product.family: To be filled by O.E.M. dmi.product.name: System Product Name dmi.product.sku: SKU dmi.product.version: System Version dmi.sys.vendor: ASUS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167785/+subscriptions

[Bug 2161312] Re: System hangs on suspend (s2idle) with kernel 7.0.0-28-generic, works fine on 7.0.0-27

## Update (2026-09-20): failure rate has jumped — 5 hangs in 8 days, 0 in the previous 4 weeks; two more silent freezes on plain s2idle suspend entry Two more hangs on 2026-09-19, both on a plain suspend (no hibernate involved in the failing step), same signature as before: journal ends right after "PM: suspend entry (s2idle)", keyboard backlight stays lit, no reaction to any key/power short-press, hard power-off required. Next boot: dirty EFI partition, systemd-journald "corrupted or uncleanly shut down", orphan inode cleanup. - 10:12:39 — second suspend request issued 6 s after a very short first suspend (woken immediately by AC plug-in). It was a suspend-then-hibernate request (default 2h delay); the machine froze on s2idle entry itself, not at the RTC wake. - 20:42:03 — suspend requested 16 s after a successful 1h42 suspend/resume. Machine stayed frozen ~9.5 h until a forced reboot. ## Statistics (journal analysis, 450 suspend/hibernate entry/exit events since 2026-08-15) - Suspend/hibernate entries issued < 60 s after a resume: 104, of which 2 failed (both on 2026-09-19). - All other entries: 123, of which 3 failed (2026-09-12 hibernate, 2026-09-14 suspend, 2026-09-16 hibernate). - So a quick re-suspend after a resume is NOT the trigger (~2% failure rate in both groups). - However, there were **zero failures from 2026-08-15 to 2026-09-11, then 5 failures between 2026-09-12 and 2026-09-19** (roughly one per day). They happen on 7.0.0-27 and 7.0.0-31, before and after the BIOS update to 1.29.0. No firmware, graphics stack or systemd package was updated before the first failure of the series (packages updated 08-09/09: libc, perl, gnupg, curl...; 13/09: kernel 7.0.0-31, wireless-regdb). I cannot find what changed around 2026-09-12. The failures leave no usable trace (kernel is frozen before it can log; last minutes of journal are lost on power-off), so I cannot narrow the cause further from logs alone. Happy to test patches/parameters or run a debug kernel if useful (netconsole/serial capture is possible if requested). ## Hardware/software (unchanged) Dell Inspiron 14 5425, AMD Ryzen 7 5825U, AMD Barcelo iGPU (amdgpu), BIOS 1.29.0, kernel 7.0.0-31-generic, Ubuntu, KDE Plasma 6.5, Wayland. `HibernateMode=shutdown` workaround applied since 2026-09-16. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2161312 Title: System hangs on suspend (s2idle) with kernel 7.0.0-28-generic, works fine on 7.0.0-27 Status in linux package in Ubuntu: New Bug description: Hello Here is a bug occurring on my laptop. The analysis is from claude code. I hope it is relevant & complete. Thanks for your help. Summary System hangs permanently when entering suspend (s2idle) on kernel 7.0.0-28-generic; requires a hard power-off to recover. The exact same hardware suspended and resumed reliably dozens of times over 8 days on kernel 7.0.0-27-generic. The regression appeared immediately after the machine booted 7.0.0-28 for the first time — first suspend attempt on the new kernel already failed, and it failed again on the next boot. Hardware Machine: Dell Inspiron 14 5425 CPU: AMD Ryzen 7 5825U with Radeon Graphics GPU: AMD/ATI Barcelo iGPU (integrated, PCI 04:00.0) BIOS: 1.19.0 (2024-09-10) Sleep mode: only s2idle is offered by the platform (/sys/power/mem_sleep → [s2idle], no deep/S3 option available) Software Ubuntu 25.10 (Questing Quokka), KDE Plasma 6.5, Wayland session (kwin_wayland) Working kernel: linux-image-7.0.0-27-generic (7.0.0-27.27) Broken kernel: linux-image-7.0.0-28-generic (7.0.0-28.28) Steps to reproduce Boot into 7.0.0-28-generic. Trigger suspend (via systemd Suspend action / closing lid / GUI power menu). System freezes during or immediately after suspend entry: keyboard backlight stays lit, no reaction to any key or the power button short-press, screen never turns back on. Only recovery is holding the power button for a hard shutdown. Expected behavior System suspends and resumes normally, as it did consistently on 7.0.0-27-generic. Actual behavior System never comes back from suspend. journalctl shows the boot ending abruptly right after suspend entry, with no PM: suspend exit line and no orderly shutdown sequence — consistent with a full system hang, not a clean poweroff. Evidence from journalctl Working kernel (7.0.0-27), representative sample out of ~40 successful cycles between 2026-07-09 and 2026-07-17: juil. 16 19:31:46 kernel: PM: suspend entry (s2idle) juil. 17 14:48:21 kernel: PM: suspend exit Failing kernel (7.0.0-28), first attempt, boot ends here with no further log lines at all: juil. 20 10:42:38 root[18433]: Dell wakeup sources disabled - ALL including dock disconnect juil. 20 10:42:38 systemd-sleep[18388]: Performing sleep operation 'suspend'... juil. 20 10:42:38 kernel: PM: suspend entry (s2idle) [-- nothing further; next boot is a cold boot, not a resume --] Failing kernel (7.0.0-28), second attempt on a fresh boot, same pattern: juil. 20 12:32:59 systemd-sleep[26074]: Performing sleep operation 'suspend'... juil. 20 12:32:59 kernel: PM: suspend entry (s2idle) [-- nothing further --] Both failing boots are followed by a fresh cold boot (new boot ID in journalctl --list-boots), confirming the machine was hard power-cycled rather than resuming. Workaround Pinning the system to linux-image-7.0.0-27-generic (apt-mark hold) restores reliable suspend/resume. Additional notes A local dell-suspend-fix.service (disables PCI/USB/BT/WMI wakeup sources before sleep, standard workaround for this laptop's dock/eSATA wake-on-disconnect quirk) is present and unchanged across both the working and failing kernel — ruling it out as the cause. Not the known 7.0.0-28.28 AMDGPU/HMM ROCm performance regression (that one is a slowdown in compute workloads, not a hang) — this appears to be a separate, undocumented issue in the same kernel build. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-28-generic 7.0.0-28.28 ProcVersionSignature: Ubuntu 7.0.0-28.28-generic 7.0.12 Uname: Linux 7.0.0-28-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Mon Jul 20 14:19:25 2026 InstallationDate: Installed on 2025-07-09 (376 days ago) InstallationMedia: Kubuntu 25.04 "Plucky Puffin" - Release amd64 (20250417) IwDevWlp3s0Link: Not connected. MachineType: Dell Inc. Inspiron 14 5425 ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-28-generic root=UUID=b239c123-a9a4-4924-bfc7-38c39f92e79b ro quiet splash acpi_backlight=native resume=UUID=871f8b5f-e842-4660-9c64-7661287c3695 PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. SourcePackage: linux UpgradeStatus: Upgraded to resolute on 2026-07-09 (11 days ago) dmi.bios.date: 09/10/2024 dmi.bios.release: 1.19 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.19.0 dmi.board.name: 0J9C2M dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.chassis.version: 1.19.0 dmi.modalias: dmi:bvnDellInc.:bvr1.19.0:bd09/10/2024:br1.19:svnDellInc.:pnInspiron145425:pvr1.19.0:rvnDellInc.:rn0J9C2M:rvrA00:cvnDellInc.:ct10:cvr1.19.0:sku0B46:pfaInspiron: dmi.product.family: Inspiron dmi.product.name: Inspiron 14 5425 dmi.product.sku: 0B46 dmi.product.version: 1.19.0 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161312/+subscriptions

[Bug 2167764] Re: thunderbolt.host_reset=1 default tears down pre-boot UEFI PCIe tunnels, breaking external NVMe direct boot over USB4

** Description changed: Package: linux (Ubuntu) Source Package: linux - Binary: linux-image-7.0.0-31-generic (Ubuntu 26.04 LTS / 24.04 HWE / 24.10) + Binary: linux-image-7.0.0-31-generic (Ubuntu 26.04 LTS Resolute / 24.04 HWE) Upstream Subsystem: drivers/thunderbolt/ (Native Host Interface & Software Connection Manager) - Affected Hardware: Intel Meteor Lake / Arrow Lake USB4 Host Interface [8086:7ec2 / 8086:7ec4], AMD Ryzen 6000/7000/8000 USB4 routers, ASMedia ASM2464PD, Intel Goshen Ridge / Titan Ridge bridges, and external PCIe NVMe direct-boot topologies. + Affected Hardware: Intel Meteor Lake / Arrow Lake USB4 Host Interface [8086:7ec2 / 8086:7ec4], AMD Hawk Point / Phoenix USB4 Host Interface [1022:1502 / 1022:1669], ASMedia ASM2464PD, and external PCIe NVMe direct-boot topologies. + Related Bug Trackers: Launchpad Bug #2078573 (Dell Latitude 5550), Bug #2159575 (ASUS Zenbook 14, dracut), Bug #2167764. + Upstream Commits: 59a54c5f3dbd & 0fc70886569c (Stable backport cc4c94a5f6c4). + Related Issue: CVE-2024-53194 (Use-after-free in pciehp on hot remove). ================================================================================ - 1. SUMMARY OF THE DEFECT + 1. SUMMARY OF THE OBSERVATION ================================================================================ - When direct-booting Linux from an external NVMe SSD over a USB4/Thunderbolt 4 PCIe Gen 4 x4 tunnel, motherboard UEFI firmware negotiates the link and builds the PCIe tunnel. GRUB2 executes and loads vmlinuz and initrd into host RAM across this tunnel. + When booting Linux directly from an external NVMe SSD over a USB4/Thunderbolt 4 PCIe Gen 4 x4 tunnel, motherboard UEFI firmware negotiates the link and establishes the PCIe tunnel. GRUB2 executes and loads vmlinuz and initrd into host RAM across this tunnel. However, during early kernel initialization inside the initramfs, - thunderbolt.ko issues an unconditional Host Router Reset - (host_reset=true). This severs the pre-boot PCIe tunnel mid-boot, - causing nvme_probe() to encounter Master Abort (0xFFFFFFFF) and return - terminal error -ENODEV. Because the Linux driver core does not re-probe - devices that failed with -ENODEV, the root filesystem device disappears - permanently from the kernel bus, causing an initramfs timeout and - emergency rescue shell drop ("Gave up waiting for root file system - device"). + thunderbolt.ko issues a Host Router Reset (host_reset=true). This drops + the pre-boot PCIe tunnel mid-boot, causing nvme_probe() to encounter + Master Abort (0xFFFFFFFF) and return terminal error -ENODEV. Because the + storage controller is disconnected during initial bus enumeration, the + root filesystem is not discovered, dropping the system into an emergency + rescue shell ("Gave up waiting for root file system device" / "Warning: + /dev/disk/by-uuid/<UUID> does not exist"). ================================================================================ - 2. FORENSIC ROOT CAUSE: THE TEARDOWN CASCADE + 2. TECHNICAL SEQUENCE DURING EARLY BOOT ================================================================================ - Tracing drivers/thunderbolt/nhi.c and drivers/thunderbolt/tb.c isolates the exact sequence: - + Tracing drivers/thunderbolt/nhi.c and drivers/thunderbolt/tb.c details the timing: 1. nhi_probe() (drivers/thunderbolt/nhi.c:1249): - Calls nhi_reset(nhi). On USB4 v2 controllers (REG_CAPS >= 0x40), because module parameter 'host_reset' defaults to true, it writes REG_RESET_HRR (BIT 0) to memory-mapped register REG_RESET (0x39898): - iowrite32(REG_RESET_HRR, nhi->iobase + REG_RESET); - This asserts a hardware Host Router Reset. Register ADP_PCIE_CS_0 bit ADP_PCIE_CS_0_PE (Path Enable, BIT 31) is de-asserted, physically cutting the PCIe tunnel. - + Calls nhi_reset(nhi). On USB4 v2 controllers (REG_CAPS >= 0x40), because module parameter 'host_reset' defaults to true, it writes REG_RESET_HRR (BIT 0) to memory-mapped register REG_RESET (0x39898). Register ADP_PCIE_CS_0 bit ADP_PCIE_CS_0_PE (Path Enable, BIT 31) is cleared, dropping the pre-boot PCIe tunnel. The Root Port clears Presence Detect State (PDS) and DL_Active. 2. tb_start() (drivers/thunderbolt/tb.c:3066-3070): - nhi_probe() invokes tb_domain_add(tb, host_reset), which calls tb_start(tb, reset = true). - tb_start() enforces: - if (reset && tb_switch_is_usb4(tb->root_switch)) { - discover = false; - if (usb4_switch_version(tb->root_switch) == 1) - tb_switch_reset(tb->root_switch); - } - Because discover is set to false, tb_discover_tunnels() and tb_scan_switch() are completely bypassed. - - 3. Asynchronous Driver Collision (drivers/nvme/host/pci.c): - Concurrently, nvme_probe() attempts to enumerate the storage controller at the pre-boot ACPI/PCI address. Because the tunnel has been severed: - nvme 0000:06:00.0: Unable to change power state from D3cold to D0, device inaccessible - nvme 0000:06:00.0: error -ENODEV: probe failed - Under Linux driver core semantics, an endpoint that fails probe with -ENODEV is never re-probed. Even when thunderbolt.ko eventually re-enumerates the enclosure seconds later, it generates thunderbolt bus uevents, not PCI bus uevents. The root partition UUID is never detected by dracut/systemd, rendering 'rootdelay=' parameters ineffective. + Because reset == true, tb_start() sets discover = false, bypassing native tunnel discovery (tb_discover_tunnels()). + 3. Driver Probing Timing (drivers/nvme/host/pci.c): + Concurrently, nvme_probe() attempts to enumerate the storage controller at the pre-boot address while the link is down. It receives Master Abort and returns terminal error -ENODEV. Under standard Linux driver core semantics, an endpoint that fails probing with -ENODEV is not automatically re-probed. ================================================================================ - 3. EMPIRICAL HARDWARE PROOF: BUILT-IN ADOPTION ALREADY EXISTS + 3. OBSERVATIONS ON USERSPACE AUTHORIZATION VS. IN-KERNEL TUNNEL PRESERVATION ================================================================================ - Empirical testing on live physical hardware (Intel Core Ultra 9 275HX Arrow Lake-HX with WD_BLACK SN7100 in ASM2464PD) proves that the Thunderbolt driver ALREADY POSSESSES complete architectural infrastructure to support pre-boot boot tunnels. + In Launchpad Bug #2078573, an initial hypothesis was considered where userspace tooling (such as boltd or udev rules inside the initramfs) might handle re-authorizing the device after the reset. - When booted with 'thunderbolt.host_reset=0': - - nhi_reset() is bypassed: the hardware PCIe tunnel remains uninterrupted. - - tb_start() retains discover = true. - - tb_discover_tunnels() executes tb_tunnel_discover_pci(), locates the active pre-boot PCIe tunnel, and marks intermediate switches as parent->boot = true. - - In tb_scan_finalize_switch(), sw->boot triggers automated switch authorization (sw->authorized = 1) before userspace uevents fire. - - Live sysfs telemetry confirms pre-boot adoption: - $ cat /sys/bus/thunderbolt/devices/0-1/boot - 1 - $ cat /sys/bus/thunderbolt/devices/0-1/authorized - 1 - - Performance & Flash Endurance when tunnel is preserved: - - PCIe Gen 4.0 x4 at 16.0 GT/s (~64 Gbps physical link). - - Buffered disk read: 3,587.60 MB/s; Direct sequential write: 2,024.33 MB/s. - - Host Memory Buffer (HMB): 64 MB host DDR5 RAM allocated via Intel VT-d IOMMU (Write Amplification Factor drops from 6.80 under UASP to 1.88 under native NVMe, extending NAND endurance by 72%). - - The default 'host_reset=true' policy simply short-circuits this - functional subsystem. + However, subsequent testing from duplicate Bug #2159575 (ASUS Zenbook 14 running Ubuntu 26.04 LTS Resolute on dracut) provides useful insights: + 1. Testing on Dracut: When testing Ubuntu 26.04 with dracut 110-11, the same early boot timeout occurred out of the box, showing that initramfs tooling updates alone do not resolve the timing race. + 2. PCI Driver Core Probe Lifecycle: In the initramfs emergency shell of Bug #2159575, reporter Lucas observed that manually authorizing the switch (echo 1 > /sys/bus/thunderbolt/.../authorized) did not bring up the NVMe device until followed by an explicit 'echo 1 > /sys/bus/pci/rescan'. Because bolt focuses strictly on domain security (/sys/bus/thunderbolt) and does not issue PCI bus rescans, handling this in userspace requires coordinating udev rules, D-Bus, and secondary bus rescans during early boot. + 3. In-Tree Discovery Logic: drivers/thunderbolt/tb.c already contains native infrastructure to discover pre-boot tunnels (tb_discover_tunnels()), which marks sw->boot = true and auto-authorizes devices in-kernel (sw->authorized = 1). When booted with 'thunderbolt.host_reset=0', this discovery path executes naturally, preserving the boot device without requiring userspace services. ================================================================================ - 4. UPSTREAM COMMIT GENEALOGY & MAINTAINER ASSUMPTIONS + 4. HARDWARE VERIFICATION & SILICON TELEMETRY ================================================================================ - - Commit 0fc70886569c (Mika Westerberg, Dec 2022): Introduced USB4 v2 host router reset via REG_RESET_HRR. - - Commit 59a54c5f3dbd (Sanath S / Mario Limonciello, Jan 2024): Defaulted host_reset to true to clear suboptimal boot firmware DisplayPort bandwidth tunnels (HBR2 vs HBR3) and reclaim exhausted AMD PCIe BAR space for docking stations. - - Commit 6faa39eea953 (Mika Westerberg, Feb 2024): Cemented 'discover = false' for USB4 host routers. - - Upstream maintainers operated under the unexamined assumption that all - USB4 devices are secondary, hotpluggable peripherals mounted after the - OS has booted from internal storage. They were unaware that the running - root filesystem could reside on the pre-boot PCIe tunnel. - - Related Vulnerability: CVE-2024-53194 documents how commits 0fc70886569c - and 59a54c5f3dbd cause unexpected PCIe presence drops triggering use- - after-free crashes in pciehp. + Testing on live physical hardware (Intel Core Ultra 9 275HX Arrow Lake-HX with WD_BLACK SN7100 in ASMedia ASM2464PD) confirms that preserving pre-boot tunnels maintains complete stability: + - With 'thunderbolt.host_reset=0': + * nhi_reset() is bypassed; hardware PCIe tunnel remains uninterrupted. + * tb_start() retains discover = true. + * tb_discover_tunnels() detects the pre-boot PCIe tunnel, sets parent->boot = true, and auto-authorizes the switch (sw->authorized = 1). + - Telemetry: + $ cat /sys/bus/thunderbolt/devices/0-1/boot -> 1 + $ cat /sys/bus/thunderbolt/devices/0-1/authorized -> 1 + - Performance: + * PCIe Gen 4 x4 link at 16.0 GT/s (~64 Gbps physical link). + * Buffered read: 3,587.60 MB/s; Direct write: 2,024.33 MB/s. + * Host Memory Buffer (HMB): 64 MB host DDR5 RAM cleanly allocated via Intel VT-d IOMMU (WAF dropped from 6.80 to 1.88, significantly extending NAND lifespan). ================================================================================ - 5. TESTED WORKAROUND (IMMEDIATE MITIGATION FOR USERS) + 5. PROPOSED UPSTREAM LINUX KERNEL PATCH ================================================================================ - Affected users direct-booting over USB4/TB4 can immediately work around the failure without recompiling the kernel by appending the following to GRUB_CMDLINE_LINUX in /etc/default/grub (or /etc/default/grub.d/99-usb4.cfg): + To allow the driver to distinguish between hotpluggable accessories (which benefit from a clean reset for DisplayPort renegotiation or MMIO allocation) and active boot storage (which must not be severed), drivers/thunderbolt/ can check whether an active pre-boot PCIe tunnel is present before issuing the reset: - thunderbolt.host_reset=0 thunderbolt.clx=0 pcie_port_pm=off - - Notes on parameters: - - thunderbolt.host_reset=0: Preserves the pre-boot UEFI PCIe tunnel across kernel handover. - - thunderbolt.clx=0 & pcie_port_pm=off: Prevents low-power link state retraining drops during early initqueue settling (may increase idle power draw by 1–3W on battery). - - ASM2464PD Retimer Cold Reset: If transitioning between ports or warm reboots fails to detect the drive in BIOS, a 30-second flea-power discharge (unplug AC, hold power button 30s) resets the high-speed retimer PHY state. - - ================================================================================ - 6. PROPOSED UPSTREAM LINUX KERNEL PATCH - ================================================================================ - We propose a two-tier safety guard in drivers/thunderbolt/: - 1. In nhi.c (nhi_has_active_boot_device()): Before issuing REG_RESET_HRR, check if sibling PCIe bridges on the root bus (external-facing or Thunderbolt ports) have active child devices populated by boot firmware. If active downstream devices exist, skip nhi_reset() and clear host_reset. - 2. In tb.c (tb_switch_has_active_pcie_tunnel()): In tb_start(), inspect whether any PCIe downstream adapter is enabled by boot firmware (tb_pci_port_is_enabled()). If active PCIe boot tunnels exist, do not set discover = false and do not reset the router. Allow tb_discover_tunnels() to adopt and authorize the boot storage. - - Engineering Suite & LKML Proposal Repository: - - GitHub: https://github.com/StickwoodJr/usb4-nvme-direct-boot - - Full Patch: https://github.com/StickwoodJr/usb4-nvme-direct-boot/blob/main/patches/0001-thunderbolt-preserve-pre-boot-pcie-tunnels.patch - - Automated Patch Verification Tool: scripts/apply_kernel_patch.sh (--check / --apply / --reverse) - - ```diff --- a/drivers/thunderbolt/nhi.c +++ b/drivers/thunderbolt/nhi.c @@ -1158,6 +1158,11 @@ static void nhi_reset(struct tb_nhi *nhi) return; } + if (nhi_has_active_boot_device(nhi)) { + dev_info(nhi->dev, "preserving pre-boot PCIe tunnel for active boot device\n"); + return; + } + iowrite32(REG_RESET_HRR, nhi->iobase + REG_RESET); msleep(100); - + } --- a/drivers/thunderbolt/tb.c +++ b/drivers/thunderbolt/tb.c @@ -3059,6 +3077,11 @@ static int tb_start(struct tb *tb, bool reset) tb_switch_tmu_enable(tb->root_switch); + if (tb_switch_has_active_pcie_tunnel(tb->root_switch)) { + tb_info(tb, "active PCIe boot tunnel detected, preserving topology\n"); + reset = false; + } + if (reset && tb_switch_is_usb4(tb->root_switch)) { discover = false; + if (usb4_switch_version(tb->root_switch) == 1) + + Reference standalone patch, tests, and packaging: + https://github.com/StickwoodJr/usb4-nvme-direct-boot + + ================================================================================ + 6. SUGGESTIONS FOR THE UBUNTU KERNEL TEAM + ================================================================================ + 1. Re-evaluate Launchpad Bug #2078573 under linux (Ubuntu): + Consider re-opening the kernel task in light of the -ENODEV probe timing findings and dracut test results, which indicate that kernel-side tunnel preservation is more robust than userspace initramfs hooks. + 2. Consider In-Kernel Tunnel Preservation: + Evaluate adopting conditional checks for active boot tunnels or documenting thunderbolt.host_reset=0 as the recommended setting for external direct-boot environments. + 3. Documentation: + Help provide guidance in Ubuntu release notes or documentation for users running external direct-boot NVMe configurations over USB4 / Thunderbolt. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2167764 Title: thunderbolt.host_reset=1 default tears down pre-boot UEFI PCIe tunnels, breaking external NVMe direct boot over USB4 Status in linux package in Ubuntu: New Bug description: Package: linux (Ubuntu) Source Package: linux Binary: linux-image-7.0.0-31-generic (Ubuntu 26.04 LTS Resolute / 24.04 HWE) Upstream Subsystem: drivers/thunderbolt/ (Native Host Interface & Software Connection Manager) Affected Hardware: Intel Meteor Lake / Arrow Lake USB4 Host Interface [8086:7ec2 / 8086:7ec4], AMD Hawk Point / Phoenix USB4 Host Interface [1022:1502 / 1022:1669], ASMedia ASM2464PD, and external PCIe NVMe direct-boot topologies. Related Bug Trackers: Launchpad Bug #2078573 (Dell Latitude 5550), Bug #2159575 (ASUS Zenbook 14, dracut), Bug #2167764. Upstream Commits: 59a54c5f3dbd & 0fc70886569c (Stable backport cc4c94a5f6c4). Related Issue: CVE-2024-53194 (Use-after-free in pciehp on hot remove). ================================================================================ 1. SUMMARY OF THE OBSERVATION ================================================================================ When booting Linux directly from an external NVMe SSD over a USB4/Thunderbolt 4 PCIe Gen 4 x4 tunnel, motherboard UEFI firmware negotiates the link and establishes the PCIe tunnel. GRUB2 executes and loads vmlinuz and initrd into host RAM across this tunnel. However, during early kernel initialization inside the initramfs, thunderbolt.ko issues a Host Router Reset (host_reset=true). This drops the pre-boot PCIe tunnel mid-boot, causing nvme_probe() to encounter Master Abort (0xFFFFFFFF) and return terminal error -ENODEV. Because the storage controller is disconnected during initial bus enumeration, the root filesystem is not discovered, dropping the system into an emergency rescue shell ("Gave up waiting for root file system device" / "Warning: /dev/disk/by-uuid/<UUID> does not exist"). ================================================================================ 2. TECHNICAL SEQUENCE DURING EARLY BOOT ================================================================================ Tracing drivers/thunderbolt/nhi.c and drivers/thunderbolt/tb.c details the timing: 1. nhi_probe() (drivers/thunderbolt/nhi.c:1249): Calls nhi_reset(nhi). On USB4 v2 controllers (REG_CAPS >= 0x40), because module parameter 'host_reset' defaults to true, it writes REG_RESET_HRR (BIT 0) to memory-mapped register REG_RESET (0x39898). Register ADP_PCIE_CS_0 bit ADP_PCIE_CS_0_PE (Path Enable, BIT 31) is cleared, dropping the pre-boot PCIe tunnel. The Root Port clears Presence Detect State (PDS) and DL_Active. 2. tb_start() (drivers/thunderbolt/tb.c:3066-3070): Because reset == true, tb_start() sets discover = false, bypassing native tunnel discovery (tb_discover_tunnels()). 3. Driver Probing Timing (drivers/nvme/host/pci.c): Concurrently, nvme_probe() attempts to enumerate the storage controller at the pre-boot address while the link is down. It receives Master Abort and returns terminal error -ENODEV. Under standard Linux driver core semantics, an endpoint that fails probing with -ENODEV is not automatically re-probed. ================================================================================ 3. OBSERVATIONS ON USERSPACE AUTHORIZATION VS. IN-KERNEL TUNNEL PRESERVATION ================================================================================ In Launchpad Bug #2078573, an initial hypothesis was considered where userspace tooling (such as boltd or udev rules inside the initramfs) might handle re-authorizing the device after the reset. However, subsequent testing from duplicate Bug #2159575 (ASUS Zenbook 14 running Ubuntu 26.04 LTS Resolute on dracut) provides useful insights: 1. Testing on Dracut: When testing Ubuntu 26.04 with dracut 110-11, the same early boot timeout occurred out of the box, showing that initramfs tooling updates alone do not resolve the timing race. 2. PCI Driver Core Probe Lifecycle: In the initramfs emergency shell of Bug #2159575, reporter Lucas observed that manually authorizing the switch (echo 1 > /sys/bus/thunderbolt/.../authorized) did not bring up the NVMe device until followed by an explicit 'echo 1 > /sys/bus/pci/rescan'. Because bolt focuses strictly on domain security (/sys/bus/thunderbolt) and does not issue PCI bus rescans, handling this in userspace requires coordinating udev rules, D-Bus, and secondary bus rescans during early boot. 3. In-Tree Discovery Logic: drivers/thunderbolt/tb.c already contains native infrastructure to discover pre-boot tunnels (tb_discover_tunnels()), which marks sw->boot = true and auto-authorizes devices in-kernel (sw->authorized = 1). When booted with 'thunderbolt.host_reset=0', this discovery path executes naturally, preserving the boot device without requiring userspace services. ================================================================================ 4. HARDWARE VERIFICATION & SILICON TELEMETRY ================================================================================ Testing on live physical hardware (Intel Core Ultra 9 275HX Arrow Lake-HX with WD_BLACK SN7100 in ASMedia ASM2464PD) confirms that preserving pre-boot tunnels maintains complete stability: - With 'thunderbolt.host_reset=0': * nhi_reset() is bypassed; hardware PCIe tunnel remains uninterrupted. * tb_start() retains discover = true. * tb_discover_tunnels() detects the pre-boot PCIe tunnel, sets parent->boot = true, and auto-authorizes the switch (sw->authorized = 1). - Telemetry: $ cat /sys/bus/thunderbolt/devices/0-1/boot -> 1 $ cat /sys/bus/thunderbolt/devices/0-1/authorized -> 1 - Performance: * PCIe Gen 4 x4 link at 16.0 GT/s (~64 Gbps physical link). * Buffered read: 3,587.60 MB/s; Direct write: 2,024.33 MB/s. * Host Memory Buffer (HMB): 64 MB host DDR5 RAM cleanly allocated via Intel VT-d IOMMU (WAF dropped from 6.80 to 1.88, significantly extending NAND lifespan). ================================================================================ 5. PROPOSED UPSTREAM LINUX KERNEL PATCH ================================================================================ To allow the driver to distinguish between hotpluggable accessories (which benefit from a clean reset for DisplayPort renegotiation or MMIO allocation) and active boot storage (which must not be severed), drivers/thunderbolt/ can check whether an active pre-boot PCIe tunnel is present before issuing the reset: --- a/drivers/thunderbolt/nhi.c +++ b/drivers/thunderbolt/nhi.c @@ -1158,6 +1158,11 @@ static void nhi_reset(struct tb_nhi *nhi) return; } + if (nhi_has_active_boot_device(nhi)) { + dev_info(nhi->dev, "preserving pre-boot PCIe tunnel for active boot device\n"); + return; + } + iowrite32(REG_RESET_HRR, nhi->iobase + REG_RESET); msleep(100); } --- a/drivers/thunderbolt/tb.c +++ b/drivers/thunderbolt/tb.c @@ -3059,6 +3077,11 @@ static int tb_start(struct tb *tb, bool reset) tb_switch_tmu_enable(tb->root_switch); + if (tb_switch_has_active_pcie_tunnel(tb->root_switch)) { + tb_info(tb, "active PCIe boot tunnel detected, preserving topology\n"); + reset = false; + } + if (reset && tb_switch_is_usb4(tb->root_switch)) { discover = false; if (usb4_switch_version(tb->root_switch) == 1) Reference standalone patch, tests, and packaging: https://github.com/StickwoodJr/usb4-nvme-direct-boot ================================================================================ 6. SUGGESTIONS FOR THE UBUNTU KERNEL TEAM ================================================================================ 1. Re-evaluate Launchpad Bug #2078573 under linux (Ubuntu): Consider re-opening the kernel task in light of the -ENODEV probe timing findings and dracut test results, which indicate that kernel-side tunnel preservation is more robust than userspace initramfs hooks. 2. Consider In-Kernel Tunnel Preservation: Evaluate adopting conditional checks for active boot tunnels or documenting thunderbolt.host_reset=0 as the recommended setting for external direct-boot environments. 3. Documentation: Help provide guidance in Ubuntu release notes or documentation for users running external direct-boot NVMe configurations over USB4 / Thunderbolt. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167764/+subscriptions

[Bug 2167772] Re: vboxsf: endless write loop and data corruption on short copy

** Tags added: kernel-daily-bug -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2167772 Title: vboxsf: endless write loop and data corruption on short copy Status in linux package in Ubuntu: New Bug description: [Summary] Writing to a VirtualBox shared folder (vboxsf) from pages that have not been faulted in makes the in-kernel vboxsf driver loop forever: the target file keeps growing with zeroed data until the disk is full, the writing process only dies on SIGKILL, and the log fills up with WARNING: lib/iov_iter.c:624 at iov_iter_revert+0x1fc/0x270 In my case ~16 GB of logs were written before the guest ran out of space. [Root cause] vboxsf_write_end() ignores "copied": it writes the full requested length to the host and returns that length even when copied == 0, so generic_perform_write() never faults the source pages in, advances pos and loops forever. The same accounting bug can silently corrupt data when the folio is already uptodate. [Upstream] Patch submitted to the vboxsf maintainer and linux-fsdevel on 2026-09-19: https://lore.kernel.org/linux-fsdevel/20260919174136.3325-1-k.shiomi@techhowto.blog/ A DKMS package with the patch (and a guard that refuses to mount shared folders unless the patched module is loaded) is available at https://github.com/kentaro-shiomi/virtualbox-vboxsf-endless-write-loop-fix [Trigger] Programs that write straight from an mmap of another file or from shared memory without reading it first. virtiofsd does exactly this, so running a nested VM whose working directory lives on a vboxsf mount hits it immediately. Ordinary applications write from buffers they have just filled and are not affected. [Environment] Ubuntu 26.04.1, kernel 7.0.0-31-generic, guest of VirtualBox 7.2.16 on a Windows 11 host. The faulty code is identical in Linux v7.0 and in master as of 2026-09. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167772/+subscriptions

[Bug 2159581] Re: Audio regression: No internal speaker sound over sof-soundwire (headphone jack works) on Intel Panther Lake layout

[Expired for linux (Ubuntu) because there has been no activity for 60 days.] ** Changed in: linux (Ubuntu) Status: Incomplete => Expired -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2159581 Title: Audio regression: No internal speaker sound over sof-soundwire (headphone jack works) on Intel Panther Lake layout Status in linux package in Ubuntu: Expired Bug description: SoundWire subsystem detects internal endpoints cleanly as "Speakers - sof-soundwire". Userspace audio mixers fluctuate dynamically showing active playback, but the physical internal speaker amplifiers remain completely silent. The onboard headphone jack (HDA) works flawlessly. System is running Ubuntu 26.04 with kernel 7.0.0-generic. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-27-generic 7.0.0-27.27 ProcVersionSignature: Ubuntu 7.0.0-27.27-generic 7.0.6 Uname: Linux 7.0.0-27-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: fpm 4351 F.... wireplumber /dev/snd/seq: fpm 4331 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sat Jul 4 19:06:12 2026 InstallationDate: Installed on 2026-07-04 (0 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) MachineType: Micro-Star International Co., Ltd. Prestige 16 AI+ C3MTG ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 xedrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-27-generic root=UUID=51afb7b2-3a6b-47e2-bef2-80c2eea73664 ro quiet splash xe.force_probe=b080 xe.enable_psr=0 crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/25/2026 dmi.bios.release: 1.21 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: E2622IMS.115 dmi.board.asset.tag: Default string dmi.board.name: MS-2622 dmi.board.vendor: Micro-Star International Co., Ltd. dmi.board.version: REV:1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: Micro-Star International Co., Ltd. dmi.chassis.version: N/A dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvrE2622IMS.115:bd03/25/2026:br1.21:svnMicro-StarInternationalCo.,Ltd.:pnPrestige16AI+C3MTG:pvrREV1.0:rvnMicro-StarInternationalCo.,Ltd.:rnMS-2622:rvrREV1.0:cvnMicro-StarInternationalCo.,Ltd.:ct10:cvrN/A:sku2622.1:pfaPrestige: dmi.product.family: Prestige dmi.product.name: Prestige 16 AI+ C3MTG dmi.product.sku: 2622.1 dmi.product.version: REV:1.0 dmi.sys.vendor: Micro-Star International Co., Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2159581/+subscriptions

[Bug 1786013] Autopkgtest regression report (linux-restricted-modules-lowlatency-hwe-6.8/6.8.0-139.139.1~22.04.1+2)

All autopkgtests for the newly accepted linux-restricted-modules-lowlatency-hwe-6.8 (6.8.0-139.139.1~22.04.1+2) for jammy have finished running. The following regressions have been reported in tests triggered by the package: nvidia-graphics-drivers-470-server/470.256.02-0ubuntu0.22.04.1 (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://ubuntu-archive-team.ubuntu.com/proposed- migration/jammy/update_excuses.html#linux-restricted-modules-lowlatency- hwe-6.8 [1] https://documentation.ubuntu.com/project/SRU/howto/autopkgtest- failure/ Thank you! -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/1786013 Title: Packaging resync Status in linux package in Ubuntu: Fix Released Status in linux-azure package in Ubuntu: Fix Released Status in linux-azure-edge package in Ubuntu: Fix Released Status in linux source package in Precise: Fix Released Status in linux-azure source package in Precise: Won't Fix Status in linux-azure-edge source package in Precise: Won't Fix Status in linux source package in Trusty: Fix Released Status in linux-azure source package in Trusty: Fix Released Status in linux-azure-edge source package in Trusty: Won't Fix Status in linux source package in Xenial: Fix Released Status in linux-azure source package in Xenial: Fix Released Status in linux-azure-edge source package in Xenial: Fix Released Status in linux source package in Bionic: Fix Released Status in linux-azure source package in Bionic: Fix Released Status in linux-azure-edge source package in Bionic: Fix Released Status in linux source package in Cosmic: Fix Released Status in linux-azure source package in Cosmic: Fix Released Status in linux-azure-edge source package in Cosmic: Won't Fix Status in linux source package in Disco: Fix Released Status in linux-azure source package in Disco: Fix Released Status in linux-azure-edge source package in Disco: Won't Fix Bug description: Ongoing packaging resyncs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1786013/+subscriptions

[Bug 1786013] Autopkgtest regression report (linux-restricted-modules-aws-6.8/6.8.0-1064.67~22.04.1+2)

All autopkgtests for the newly accepted linux-restricted-modules-aws-6.8 (6.8.0-1064.67~22.04.1+2) for jammy have finished running. The following regressions have been reported in tests triggered by the package: nvidia-graphics-drivers-470-server/470.256.02-0ubuntu0.22.04.1 (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://ubuntu-archive-team.ubuntu.com/proposed- migration/jammy/update_excuses.html#linux-restricted-modules-aws-6.8 [1] https://documentation.ubuntu.com/project/SRU/howto/autopkgtest- failure/ Thank you! -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/1786013 Title: Packaging resync Status in linux package in Ubuntu: Fix Released Status in linux-azure package in Ubuntu: Fix Released Status in linux-azure-edge package in Ubuntu: Fix Released Status in linux source package in Precise: Fix Released Status in linux-azure source package in Precise: Won't Fix Status in linux-azure-edge source package in Precise: Won't Fix Status in linux source package in Trusty: Fix Released Status in linux-azure source package in Trusty: Fix Released Status in linux-azure-edge source package in Trusty: Won't Fix Status in linux source package in Xenial: Fix Released Status in linux-azure source package in Xenial: Fix Released Status in linux-azure-edge source package in Xenial: Fix Released Status in linux source package in Bionic: Fix Released Status in linux-azure source package in Bionic: Fix Released Status in linux-azure-edge source package in Bionic: Fix Released Status in linux source package in Cosmic: Fix Released Status in linux-azure source package in Cosmic: Fix Released Status in linux-azure-edge source package in Cosmic: Won't Fix Status in linux source package in Disco: Fix Released Status in linux-azure source package in Disco: Fix Released Status in linux-azure-edge source package in Disco: Won't Fix Bug description: Ongoing packaging resyncs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1786013/+subscriptions

[Bug 1786013] Autopkgtest regression report (linux-restricted-modules/5.15.0-198.208+1)

All autopkgtests for the newly accepted linux-restricted-modules (5.15.0-198.208+1) for jammy have finished running. The following regressions have been reported in tests triggered by the package: nvidia-graphics-drivers-390/390.157-0ubuntu0.22.04.2 (amd64, armhf, i386) nvidia-graphics-drivers-450-server/450.248.02-0ubuntu0.22.04.1 (amd64) nvidia-graphics-drivers-470-server/470.256.02-0ubuntu0.22.04.1 (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://ubuntu-archive-team.ubuntu.com/proposed- migration/jammy/update_excuses.html#linux-restricted-modules [1] https://documentation.ubuntu.com/project/SRU/howto/autopkgtest- failure/ Thank you! -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/1786013 Title: Packaging resync Status in linux package in Ubuntu: Fix Released Status in linux-azure package in Ubuntu: Fix Released Status in linux-azure-edge package in Ubuntu: Fix Released Status in linux source package in Precise: Fix Released Status in linux-azure source package in Precise: Won't Fix Status in linux-azure-edge source package in Precise: Won't Fix Status in linux source package in Trusty: Fix Released Status in linux-azure source package in Trusty: Fix Released Status in linux-azure-edge source package in Trusty: Won't Fix Status in linux source package in Xenial: Fix Released Status in linux-azure source package in Xenial: Fix Released Status in linux-azure-edge source package in Xenial: Fix Released Status in linux source package in Bionic: Fix Released Status in linux-azure source package in Bionic: Fix Released Status in linux-azure-edge source package in Bionic: Fix Released Status in linux source package in Cosmic: Fix Released Status in linux-azure source package in Cosmic: Fix Released Status in linux-azure-edge source package in Cosmic: Won't Fix Status in linux source package in Disco: Fix Released Status in linux-azure source package in Disco: Fix Released Status in linux-azure-edge source package in Disco: Won't Fix Bug description: Ongoing packaging resyncs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1786013/+subscriptions

[Bug 2167742] Re: Intel AX210 iwlwifi microcode crash with "Device error - SW reset" and connection drops

** Tags added: kernel-daily-bug -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2167742 Title: Intel AX210 iwlwifi microcode crash with "Device error - SW reset" and connection drops Status in linux package in Ubuntu: New Bug description: 1) Ubuntu Release: Ubuntu 26.04.1 LTS Kernel: 7.0.0-31-generic 2) Package / Hardware Info: Motherboard: ASUS ROG STRIX B660-F GAMING WIFI Wireless Chip: Intel Wi-Fi 6E AX210 160MHz [8086:2725] (rev 1a) Kernel Driver: iwlwifi 3) What expected to happen: Wi-Fi connection should remain stable without sudden disconnects during normal operation. 4) What happened instead: The wireless connection drops unexpectedly due to driver/firmware microcode crash, forcing the hardware to restart. Relevant dmesg / kernel log snippets: - iwlwifi 0000:05:00.0: Device error - SW reset - iwlwifi 0000:05:00.0: Failed to send the temperature measurement command (err=-5) - ieee80211 phy0: Hardware restart was requested The issue started occurring recently after system package updates. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-31-generic 7.0.0-31.31 ProcVersionSignature: Ubuntu 7.0.0-31.31-generic 7.0.14 Uname: Linux 7.0.0-31-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sat Sep 19 03:02:32 2026 InstallationDate: Installed on 2026-08-21 (29 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) MachineType: ASUS System Product Name ProcFB: 0 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-31-generic root=UUID=f02dfac3-6451-4c86-af06-6ad386be97f9 ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 05/14/2025 dmi.bios.release: 38.1 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 3801 dmi.board.asset.tag: Default string dmi.board.name: ROG STRIX B660-F GAMING WIFI dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev 1.xx dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr3801:bd05/14/2025:br38.1:svnASUS:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnROGSTRIXB660-FGAMINGWIFI:rvrRev1.xx:cvnDefaultstring:ct3:cvrDefaultstring:skuSKU:pfaTobefilledbyO.E.M.: dmi.product.family: To be filled by O.E.M. dmi.product.name: System Product Name dmi.product.sku: SKU dmi.product.version: System Version dmi.sys.vendor: ASUS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167742/+subscriptions

[Bug 2159596] Re: amdgpu fails to come up due to BAR issue when at PCIe root

The upstream fix is now queued: commit d58384c22739, "PCI: Fix BAR resize for devices on a root bus", in Bjorn Helgaas's PCI tree (git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git, branch pci/for-linus), committed 2026-09-18 for the current 7.3 cycle. Reviewed-by: Ilpo Järvinen, Cc: stable. Patch thread: https://patch.msgid.link/20260918035633.566823-1-lizf@honeycomb.io Request: please cherry-pick this into both affected Ubuntu 7.0 kernels: the resolute 7.0 kernel and linux-hwe-7.0 in noble, which is installed by default from the 24.04.5 point release, so this reaches a default install and not just opt-in HWE users. Upstream stable will only carry the fix to 7.2.y (6.19.y, 7.0.y and 7.1.y are EOL), so it will not arrive via a 7.0.y stable update. Impact: when a device sits directly on a PCI root bus (bus->self == NULL, e.g. the SolidRun HoneyComb LX2K, where the AMD dGPU has no root port), pci_resize_resource() releases the device's BARs and returns success without reassigning them. amdgpu then fails init (gmc_v8_0 sw_init failed -19). Regression introduced upstream by 337b1b566db0 (v6.19). Fix: with no upstream bridge, call pci_bus_assign_resources() on the root bus to place the released BARs. It also fixes an unbalanced pci_bus_sem up_read() on that path. Testing: applied to the resolute 7.0.0-31.31 source (hunk offsets only), built with pdebuild and booted on the affected hardware. amdgpu initializes with the full 4096M BAR with the amdgpu.rebar=0 workaround removed. I also exercised the resize path directly via the resource0_resize sysfs attribute, shrinking to 256M and growing back to 4G, with a clean release/assign each way. Regression potential: confined to pci_do_resource_release_and_resize(). The bridged path's logic is unchanged apart from taking pci_bus_sem before the BAR release loop. Workaround until then: amdgpu.rebar=0. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2159596 Title: amdgpu fails to come up due to BAR issue when at PCIe root Status in linux package in Ubuntu: Triaged Status in linux-hwe-7.0 package in Ubuntu: Triaged Bug description: With the 7.0 hwe kernel on 24.04 (and presumably also the 7.0 kernel on 26.04), amdgpu completely fails to init on the SolidRun HoneyComb LX2 (NXP LX2160A, arm64, ACPI), where the GPU endpoint is enumerated directly on the root bus of its segment (there is no root port device, so pdev->bus->self is NULL):   amdgpu 0004:01:00.0: BAR 0 [mem 0xa400000000-0xa40fffffff 64bit pref]: releasing   amdgpu 0004:01:00.0: BAR 2 [mem 0xa410000000-0xa4101fffff 64bit pref]: releasing   amdgpu 0004:01:00.0: sw_init of IP block <gmc_v8_0> failed -19   amdgpu 0004:01:00.0: amdgpu_device_ip_init failed   amdgpu 0004:01:00.0: Fatal error during GPU init No error is logged because the resize path reports success; amdgpu then finds BAR0 IORESOURCE_UNSET and bails out with -ENODEV. Observed at runtime on Ubuntu's linux-hwe-7.0 (7.0.0-14, broken) vs linux-hwe-6.17 (working), but nothing here is distro-specific: Ubuntu carries this code unmodified, and the affected function is identical to current mainline. By source inspection the regression window is v6.18 (old code paths) to v6.19 (consolidation). See https://lkml.org/lkml/2026/7/5/502 for full description and patch. Workaround is to disable resizable BAR using amdgpu.rebar=0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2159596/+subscriptions

[Bug 2167571] Re: [SRU] Fix excessive internal microphone gain causing noisy recordings on Yoga Pro 7

** Description changed: [ Impact ] The internal microphone on affected Yoga Pro 7 systems records with excessive background noise when mic volume is set to 100%. The gain is stuck at the maximum level (Amp-In 0x03 / 29.25 dB), which makes hiss/static clearly audible and impacts normal audio recording use. + + kernel: 7.0.0 + ubuntu: 24.04 or 26.04 + [ Test Plan ] 1. Boot an affected Yoga Pro 7 system with the SRU kernel. 2. Set internal mic volume to 100%. 3. Record audio with the internal microphone. 4. Verify the recording no longer has excessive hiss/static and the gain no longer stays pinned at Amp-In 0x03. [ Where problems could occur ] This change affects the codec gain path, so a regression could make the internal microphone too quiet or alter input levels on related audio paths. [ Other Info ] The upstream fix is already merged in Linux kernel commit 6cd3d2c82651a9e77aa5b1b9c12aa918c0d6c0a9. https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=6cd3d2c82651a9e77aa5b1b9c12aa918c0d6c0a9 -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2167571 Title: [SRU] Fix excessive internal microphone gain causing noisy recordings on Yoga Pro 7 Status in linux package in Ubuntu: New Bug description: [ Impact ] The internal microphone on affected Yoga Pro 7 systems records with excessive background noise when mic volume is set to 100%. The gain is stuck at the maximum level (Amp-In 0x03 / 29.25 dB), which makes hiss/static clearly audible and impacts normal audio recording use. kernel: 7.0.0 ubuntu: 24.04 or 26.04 [ Test Plan ] 1. Boot an affected Yoga Pro 7 system with the SRU kernel. 2. Set internal mic volume to 100%. 3. Record audio with the internal microphone. 4. Verify the recording no longer has excessive hiss/static and the gain no longer stays pinned at Amp-In 0x03. [ Where problems could occur ] This change affects the codec gain path, so a regression could make the internal microphone too quiet or alter input levels on related audio paths. [ Other Info ] The upstream fix is already merged in Linux kernel commit 6cd3d2c82651a9e77aa5b1b9c12aa918c0d6c0a9. https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=6cd3d2c82651a9e77aa5b1b9c12aa918c0d6c0a9 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167571/+subscriptions

[Bug 2167344] Re: FCoE not supported with HPE Synergy 4820C and 6820C CNA cards

What kernel version are using? Is this on resolute? -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2167344 Title: FCoE not supported with HPE Synergy 4820C and 6820C CNA cards Status in linux package in Ubuntu: New Bug description: According to https://support.hpe.com/hpesc/public/docDisplay?docId=a00129603en_us, FCoE is not supported on Ubuntu 20.04 and up. It may be linked to an in-tree driver limitation, but we currently lack visibility into the technical details. This bug report will allow tracking from HPE. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167344/+subscriptions