[Bug 2167904] [NEW] xternal monitor fails EDID detection through Dell WD25Z dock

Public bug reported: # Bug report: External monitor fails EDID detection through Dell WD25Z dock (separate from known UCSI duplicate-altmode bug) ## Summary One external monitor connected via DisplayPort to a Dell Pro Dock WD25Z is never assigned a valid EDID by the kernel, and is limited to a small set of generic fallback resolutions (max 1024x768) instead of its native 1920x1080. A second external monitor connected via DisplayPort to the same dock, and the same monitor/cable/port under Windows 11, work correctly at 1920x1080. This report also documents a related, already- fixed UCSI firmware-duplicate-altmode bug encountered on the same hardware, which is **not** the cause of the EDID issue but was investigated in the same session and may be relevant context. ## System information - **Laptop:** Dell Latitude 7420 (BIOS 1.51.0 and 1.52.0 both tested, no change) - **OS:** Ubuntu 26.04.1 LTS - **Kernels tested:** - `7.0.0-31-generic` (default Ubuntu kernel) - `7.1.13-070113-generic` (mainline build from kernel.ubuntu.com, includes upstream commit `67c92c6419ea6dbc5b1f3e9691aecea956e3e81c`) - **Dock:** Dell Pro Dock WD25Z (USB4/DisplayPort Alt Mode; does not negotiate as a Thunderbolt device — confirmed absent from `boltctl` output and from Windows' Thunderbolt Control Center on both ports) - **Affected monitor:** connected via DisplayPort on the dock - **Working monitor for comparison:** LG Electronics 22" (model reports as "LG FULL HD"), connected via a second DisplayPort output on the same dock ## Steps to reproduce 1. Connect the Dell WD25Z dock to the Latitude 7420 via USB-C. 2. Connect two external monitors to the dock's two DisplayPort outputs (one HDMI + one DP was also tested with the same result on the DP-connected monitor). 3. Boot Ubuntu. ## Expected behaviour Both external monitors are detected with correct EDID (vendor/product/serial) and offer their native 1920x1080 resolution, as happens under Windows 11 on the same hardware. ## Actual behaviour - One monitor (LG) is detected correctly every time. - The other monitor is detected as "Unknown Display" (GNOME/Mutter) with `Vendor: unknown`, `Product: unknown`, `Serial: unknown`, and is limited to a short list of fallback modes (`1024x768@60.004`, `848x480@60.000`, `800x600@60.317`, `800x600@56.250`, `640x480@59.940`) with no 1920x1080 option. - `/sys/class/drm/cardX-DP-Y/edid` for the affected connector reads back **0 bytes**, while the working monitor's EDID reads back correctly at the same time. - The DRM connector number assigned to the affected monitor changes on every boot and every resume from suspend (observed as `DP-5`, `DP-6`, `DP-9`, `DP-10` across different sessions for what is physically the same port), consistent with the dock's internal MST/DP hub re-enumerating non-deterministically. - DisplayPort Alt Mode itself negotiates successfully on the USB-C link for this monitor: `/sys/class/typec/portN/portN-partner/portN-partner.X/active` = `yes` with the DisplayPort mode active. The failure appears to be downstream, in the actual DP-AUX/EDID read over the dock's internal hub for this specific output. ## Separate, already-resolved issue encountered during investigation While investigating, the following kernel WARNING was found on kernel `7.0.0-31-generic` when hot-plugging the dock: ``` ucsi_acpi USBC000:00: con2: Firmware bug: duplicate partner altmode SVID 0x413c (VDO 0x00000001 vs 0x00000002) at offset 2, ignoring. Please update your system firmware. ------------[ cut here ]------------ WARNING: drivers/usb/typec/class.c:311 at typec_altmode_update_active+0x101/0x110 [typec] ... Call Trace: ucsi_altmode_update_active+0x116/0x1b0 [typec_ucsi] ucsi_check_altmodes+0x92/0xd0 [typec_ucsi] ucsi_poll_worker+0x41/0xe0 [typec_ucsi] ``` This matches the upstream fix "usb: typec: ucsi: Detect and skip duplicate altmodes from buggy firmware" (commit `67c92c6419ea6dbc5b1f3e9691aecea956e3e81c`, landed for v7.1.6/v7.2). After building and booting mainline kernel `7.1.13`, this WARNING/call trace no longer occurs. However: - `/sys/class/typec/port1/port1.2/` and `port1.3/` (port side) and `port1-partner.1/` and `.2/` (partner side) still both advertise SVID `413c` with distinct VDOs (`0x00000001` and `0x00000002`) — the duplication is still present in the dock's firmware, it is simply no longer causing a kernel warning/crash, which appears to be intentional given the port itself also advertises the SVID twice (a case the current fix logic treats as tolerable rather than as the "buggy firmware" case it filters). - **This fix did not resolve the EDID/resolution issue**, which persisted identically on kernel 7.1.13. The two issues are independent. I am not certain whether the EDID read failure is best classified as a kernel/DRM driver issue, a udev/enumeration-ordering issue, or purely a dock firmware issue outside the kernel's control — filing here in case it's the former, and in parallel reporting to Dell in case it's a dock firmware issue. ## Workaround currently in use Forcing a synthetic EDID via the `drm.edid_firmware` kernel parameter, mapped to the range of connector names observed across boots, restores 1920x1080 output but does not restore correct monitor identification and is not a real fix for the underlying EDID read failure or the connector renumbering. ## Additional information available on request - Full `dmesg` output from both kernel versions - `xrandr --verbose` output - `gdctl show --modes` output - `/sys/class/typec/` and `/sys/class/drm/` sysfs dumps ## Report generated by Claude AI ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2167904 Title: xternal monitor fails EDID detection through Dell WD25Z dock Status in linux package in Ubuntu: New Bug description: # Bug report: External monitor fails EDID detection through Dell WD25Z dock (separate from known UCSI duplicate-altmode bug) ## Summary One external monitor connected via DisplayPort to a Dell Pro Dock WD25Z is never assigned a valid EDID by the kernel, and is limited to a small set of generic fallback resolutions (max 1024x768) instead of its native 1920x1080. A second external monitor connected via DisplayPort to the same dock, and the same monitor/cable/port under Windows 11, work correctly at 1920x1080. This report also documents a related, already-fixed UCSI firmware-duplicate-altmode bug encountered on the same hardware, which is **not** the cause of the EDID issue but was investigated in the same session and may be relevant context. ## System information - **Laptop:** Dell Latitude 7420 (BIOS 1.51.0 and 1.52.0 both tested, no change) - **OS:** Ubuntu 26.04.1 LTS - **Kernels tested:** - `7.0.0-31-generic` (default Ubuntu kernel) - `7.1.13-070113-generic` (mainline build from kernel.ubuntu.com, includes upstream commit `67c92c6419ea6dbc5b1f3e9691aecea956e3e81c`) - **Dock:** Dell Pro Dock WD25Z (USB4/DisplayPort Alt Mode; does not negotiate as a Thunderbolt device — confirmed absent from `boltctl` output and from Windows' Thunderbolt Control Center on both ports) - **Affected monitor:** connected via DisplayPort on the dock - **Working monitor for comparison:** LG Electronics 22" (model reports as "LG FULL HD"), connected via a second DisplayPort output on the same dock ## Steps to reproduce 1. Connect the Dell WD25Z dock to the Latitude 7420 via USB-C. 2. Connect two external monitors to the dock's two DisplayPort outputs (one HDMI + one DP was also tested with the same result on the DP-connected monitor). 3. Boot Ubuntu. ## Expected behaviour Both external monitors are detected with correct EDID (vendor/product/serial) and offer their native 1920x1080 resolution, as happens under Windows 11 on the same hardware. ## Actual behaviour - One monitor (LG) is detected correctly every time. - The other monitor is detected as "Unknown Display" (GNOME/Mutter) with `Vendor: unknown`, `Product: unknown`, `Serial: unknown`, and is limited to a short list of fallback modes (`1024x768@60.004`, `848x480@60.000`, `800x600@60.317`, `800x600@56.250`, `640x480@59.940`) with no 1920x1080 option. - `/sys/class/drm/cardX-DP-Y/edid` for the affected connector reads back **0 bytes**, while the working monitor's EDID reads back correctly at the same time. - The DRM connector number assigned to the affected monitor changes on every boot and every resume from suspend (observed as `DP-5`, `DP-6`, `DP-9`, `DP-10` across different sessions for what is physically the same port), consistent with the dock's internal MST/DP hub re-enumerating non-deterministically. - DisplayPort Alt Mode itself negotiates successfully on the USB-C link for this monitor: `/sys/class/typec/portN/portN-partner/portN-partner.X/active` = `yes` with the DisplayPort mode active. The failure appears to be downstream, in the actual DP-AUX/EDID read over the dock's internal hub for this specific output. ## Separate, already-resolved issue encountered during investigation While investigating, the following kernel WARNING was found on kernel `7.0.0-31-generic` when hot-plugging the dock: ``` ucsi_acpi USBC000:00: con2: Firmware bug: duplicate partner altmode SVID 0x413c (VDO 0x00000001 vs 0x00000002) at offset 2, ignoring. Please update your system firmware. ------------[ cut here ]------------ WARNING: drivers/usb/typec/class.c:311 at typec_altmode_update_active+0x101/0x110 [typec] ... Call Trace: ucsi_altmode_update_active+0x116/0x1b0 [typec_ucsi] ucsi_check_altmodes+0x92/0xd0 [typec_ucsi] ucsi_poll_worker+0x41/0xe0 [typec_ucsi] ``` This matches the upstream fix "usb: typec: ucsi: Detect and skip duplicate altmodes from buggy firmware" (commit `67c92c6419ea6dbc5b1f3e9691aecea956e3e81c`, landed for v7.1.6/v7.2). After building and booting mainline kernel `7.1.13`, this WARNING/call trace no longer occurs. However: - `/sys/class/typec/port1/port1.2/` and `port1.3/` (port side) and `port1-partner.1/` and `.2/` (partner side) still both advertise SVID `413c` with distinct VDOs (`0x00000001` and `0x00000002`) — the duplication is still present in the dock's firmware, it is simply no longer causing a kernel warning/crash, which appears to be intentional given the port itself also advertises the SVID twice (a case the current fix logic treats as tolerable rather than as the "buggy firmware" case it filters). - **This fix did not resolve the EDID/resolution issue**, which persisted identically on kernel 7.1.13. The two issues are independent. I am not certain whether the EDID read failure is best classified as a kernel/DRM driver issue, a udev/enumeration-ordering issue, or purely a dock firmware issue outside the kernel's control — filing here in case it's the former, and in parallel reporting to Dell in case it's a dock firmware issue. ## Workaround currently in use Forcing a synthetic EDID via the `drm.edid_firmware` kernel parameter, mapped to the range of connector names observed across boots, restores 1920x1080 output but does not restore correct monitor identification and is not a real fix for the underlying EDID read failure or the connector renumbering. ## Additional information available on request - Full `dmesg` output from both kernel versions - `xrandr --verbose` output - `gdctl show --modes` output - `/sys/class/typec/` and `/sys/class/drm/` sysfs dumps ## Report generated by Claude AI To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167904/+subscriptions

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

All autopkgtests for the newly accepted linux-restricted-modules-nvidia-6.8 (6.8.0-1064.67~22.04.1) for jammy have finished running. The following regressions have been reported in tests triggered by the package: nvidia-graphics-drivers-470/unknown (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-nvidia-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-lowlatency-hwe-6.8/6.8.0-146.146.1~22.04.1)

All autopkgtests for the newly accepted linux-restricted-modules-lowlatency-hwe-6.8 (6.8.0-146.146.1~22.04.1) 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 2167877] Re: System update hangs on rsyslog error Sept-21-2026

** 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/2167877 Title: System update hangs on rsyslog error Sept-21-2026 Status in linux package in Ubuntu: New Bug description: System update as of Sep-21-2026 hangs on rsyslog error. -pressing cancel does nothing. Won't stop and reverse the update as expected. -the computer's fan runs profusely non stop even long after restart is issued. -system restart is the only recovery method. a screenshot of the bug is attached. 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 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: spaceship 5341 F.... wireplumber /dev/snd/controlC1: spaceship 5341 F.... wireplumber /dev/snd/seq: spaceship 5320 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Mon Sep 21 11:47:40 2026 InstallationDate: Installed on 2026-09-12 (9 days ago) InstallationMedia: Ubuntu 26.04.1 LTS "Resolute Raccoon" - Release amd64 (20260826) MachineType: Alienware Alienware m15 R3 ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-31-generic root=UUID=2dbd6c8a-00b1-44ff-b27f-9cc4be6c79fc ro quiet splash lockdown=confidentiality 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: 07/08/2026 dmi.bios.release: 1.37 dmi.bios.vendor: Alienware dmi.bios.version: 1.37.0 dmi.board.name: Alienware m15 R3 dmi.board.vendor: Alienware dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Alienware dmi.chassis.version: Not Specified dmi.modalias: dmi:bvnAlienware:bvr1.37.0:bd07/08/2026:br1.37:svnAlienware:pnAlienwarem15R3:pvr1.37.0:rvnAlienware:rnAlienwarem15R3:rvrA00:cvnAlienware:ct10:cvrNotSpecified:sku09CE:pfaAlienware: dmi.product.family: Alienware dmi.product.name: Alienware m15 R3 dmi.product.sku: 09CE dmi.product.version: 1.37.0 dmi.sys.vendor: Alienware To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167877/+subscriptions

[Bug 2031382] Re: ioprio_set03 in ubuntu_ltp_syscalls failed with J-oem-6.5 (TFAIL: ioprio_set IOPRIO_CLASS_BE prio 8 should not work)

** 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/2031382 Title: ioprio_set03 in ubuntu_ltp_syscalls failed with J-oem-6.5 (TFAIL: ioprio_set IOPRIO_CLASS_BE prio 8 should not work) Status in ubuntu-kernel-tests: New Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: New Bug description: SRU Justification: [Impact] On Jammy 6.8 series, ioprio_set system call does not return correct error value when setting IOPRIO_CLASS_BE to an invalid value. On Ubuntu Jammy, since we are using linux-klibc-dev package from 5.15 kernel the new ioprio level checking logic (added in upstream commit 893e5d32d5832674bcf6465f27958e883b72b346) resided in the 6.8 linux-klibc-dev headers will not be triggered. [Fix] Partially reverting the upstream commit eca2040972b411ec27483bf75dc8b84e730e88ff can workaround the issue. [Test Plan] Run LTP syscall testsuite `ioprio_set03` can sufficiently test the fix. [Where problems could occur] The patch could damage the ioprio_set system call handling further and cause issues with user-space applications that set the I/O priorities. [Other Info] Original bug report: Test failed with 6.5.0-1002.2. Test output: <<<test_start>>> tag=ioprio_set03 stime=1692085364 cmdline="ioprio_set03" contacts="" analysis=exit <<<test_output>>> incrementing stop tst_test.c:1558: TINFO: Timeout per run is 0h 00m 30s ioprio_set03.c:39: TFAIL: ioprio_set IOPRIO_CLASS_BE prio 8 should not work ioprio_set03.c:47: TINFO: tested illegal priority with class NONE ioprio_set03.c:50: TPASS: returned correct error for wrong prio: EINVAL (22) Summary: passed 1 failed 1 broken 0 skipped 0 warnings 0 <<<execution_status>>> initiation_status="ok" duration=0 termination_type=exited termination_id=1 corefile=no cutime=0 cstime=0 <<<test_end>>> Test case: https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/ioprio/ioprio_set03.c To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/2031382/+subscriptions

[Bug 1786013] Autopkgtest regression report (linux-restricted-modules-aws/5.15.0-1117.124)

All autopkgtests for the newly accepted linux-restricted-modules-aws (5.15.0-1117.124) 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) nvidia-graphics-drivers-390/unknown (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-aws [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 2167799] Re: Can't turn on Bluetooth

*** This bug is a duplicate of bug 2165873 *** https://bugs.launchpad.net/bugs/2165873 ** This bug has been marked a duplicate of bug 2165873 Bluetooth fails to initialize due to a kernel NULL pointer error -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2167799 Title: Can't turn on Bluetooth Status in linux package in Ubuntu: New Bug description: [Expected Behavior] Bluetooth should turn on and be able to discover devices. It works perfectly on the older kernel version [Ubuntu, with Linux: 6.8.0-138]. [Actual Behavior] After the recent September update to kernel [Ubuntu, with Linux: 6.8.0-139], Bluetooth cannot be enabled. The toggle in the settings automatically switches back to "Off". [Steps to Reproduce] 1. Boot into the latest kernel ([6.8.0-139]). 2. Open Settings -> Bluetooth. 3. Try to turn Bluetooth on. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-image-6.8.0-139-generic 6.8.0-139.139 ProcVersionSignature: Ubuntu 6.8.0-139.139-generic 6.8.12 Uname: Linux 6.8.0-139-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.28.3-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: ni 2713 F.... wireplumber /dev/snd/controlC0: ni 2713 F.... wireplumber /dev/snd/seq: ni 2708 F.... pipewire CRDA: N/A CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun Sep 20 20:03:18 2026 InstallationDate: Installed on 2025-11-08 (316 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) MachineType: ASUSTeK COMPUTER INC. ASUS TUF Gaming A15 FA506NFR_FA506NFR ProcFB: 0 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.8.0-139-generic root=UUID=760880b1-41ea-410f-8a9e-bfc6f193138b ro quiet splash pcie_aspm=off vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-6.8.0-139-generic N/A linux-backports-modules-6.8.0-139-generic N/A linux-firmware 20240318.git3b128b60.0ubuntu3.1 SourcePackage: linux UpgradeStatus: Upgraded to noble on 2025-11-08 (316 days ago) dmi.bios.date: 03/21/2024 dmi.bios.release: 5.24 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: FA506NFR.300 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: FA506NFR dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTeK COMPUTER INC. dmi.chassis.version: 1.0 dmi.ec.firmware.release: 3.0 dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvrFA506NFR.300:bd03/21/2024:br5.24:efr3.0:svnASUSTeKCOMPUTERINC.:pnASUSTUFGamingA15FA506NFR_FA506NFR:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnFA506NFR:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:sku: dmi.product.family: ASUS TUF Gaming A15 dmi.product.name: ASUS TUF Gaming A15 FA506NFR_FA506NFR dmi.product.version: 1.0 dmi.sys.vendor: ASUSTeK COMPUTER INC. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167799/+subscriptions

[Bug 2159589] Re: Bluetooth turns back on automatically after being turned off in GNOME

[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/2159589 Title: Bluetooth turns back on automatically after being turned off in GNOME Status in linux package in Ubuntu: Expired Bug description: On Ubuntu 26.04 LTS, Bluetooth cannot remain turned off. When I turn Bluetooth off using either GNOME Quick Settings or Settings, it turns off briefly but then automatically turns itself back on. The Bluetooth controller confirms this behavior: immediately after turning it off, bluetoothctl show reports: Powered: no PowerState: off After a short time, without any user action, it changes back to: Powered: yes PowerState: on The Bluetooth adapter is a MediaTek device, USB ID 0e8d:e025, on a Lenovo ThinkPad P16s Gen 4 AMD. The kernel log also showed errors during the Bluetooth power-off sequence, including: Bluetooth: hci0: command 0x2039 tx timeout Bluetooth: hci0: failed to reset (-19) Bluetooth: hci0: Error when powering off device on rfkill (-110) Expected behavior: When Bluetooth is turned off in GNOME Quick Settings or Settings, it should remain off until the user turns it on again. Actual behavior: Bluetooth turns itself back on automatically after being turned off. This occurs consistently after a fresh installation of Ubuntu 26.04 LTS. 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 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun Jul 5 14:09:07 2026 InstallationDate: Installed on 2026-07-05 (0 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) MachineType: LENOVO 21RX001LGE ProcEnviron:  LANG=en_US.UTF-8  PATH=(custom, no user)  SHELL=/bin/bash  TERM=xterm-256color  XDG_RUNTIME_DIR=<set> ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-7.0.0-27-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv 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: 08/29/2025 dmi.bios.release: 1.15 dmi.bios.vendor: LENOVO dmi.bios.version: R2XET35W (1.15 ) dmi.board.asset.tag: Not Available dmi.board.name: 21RX001LGE dmi.board.vendor: LENOVO dmi.board.version: Not Defined dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.ec.firmware.release: 1.8 dmi.modalias: dmi:bvnLENOVO:bvrR2XET35W(1.15):bd08/29/2025:br1.15:efr1.8:svnLENOVO:pn21RX001LGE:pvrThinkPadP16sGen4AMD:rvnLENOVO:rn21RX001LGE:rvrNotDefined:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_21RX_BU_Think_FM_ThinkPadP16sGen4AMD:pfaThinkPadP16sGen4AMD: dmi.product.family: ThinkPad P16s Gen 4 AMD dmi.product.name: 21RX001LGE dmi.product.sku: LENOVO_MT_21RX_BU_Think_FM_ThinkPad P16s Gen 4 AMD dmi.product.version: ThinkPad P16s Gen 4 AMD dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2159589/+subscriptions

[Bug 2031382] Re: ioprio_set03 in ubuntu_ltp_syscalls failed with J-oem-6.5 (TFAIL: ioprio_set IOPRIO_CLASS_BE prio 8 should not work)

** Also affects: linux (Ubuntu) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Jammy) Importance: Undecided Status: New ** Changed in: linux (Ubuntu) Status: New => Invalid ** Changed in: linux (Ubuntu Jammy) Assignee: (unassigned) => Zixing Liu (liushuyu-011) ** Description changed: + SRU Justification: + + [Impact] + On Jammy 6.8 series, ioprio_set system call does not return correct error value when setting IOPRIO_CLASS_BE to an invalid value. + + [Fix] + Partially reverting commit <> workaround the issue. + + [Test Plan] + Run LTP syscall testsuite `ioprio_set03` can sufficiently test the fix. + + [Where problems could occur] + The patch could damage the ioprio_set system call handling further and cause issues with user-space applications that set the I/O priorities. + + [Other Info] + Original bug report: + Test failed with 6.5.0-1002.2. Test output: <<<test_start>>> tag=ioprio_set03 stime=1692085364 cmdline="ioprio_set03" contacts="" analysis=exit <<<test_output>>> incrementing stop tst_test.c:1558: TINFO: Timeout per run is 0h 00m 30s ioprio_set03.c:39: TFAIL: ioprio_set IOPRIO_CLASS_BE prio 8 should not work ioprio_set03.c:47: TINFO: tested illegal priority with class NONE ioprio_set03.c:50: TPASS: returned correct error for wrong prio: EINVAL (22) Summary: passed 1 failed 1 broken 0 skipped 0 warnings 0 <<<execution_status>>> initiation_status="ok" duration=0 termination_type=exited termination_id=1 corefile=no cutime=0 cstime=0 <<<test_end>>> Test case: https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/ioprio/ioprio_set03.c ** Description changed: SRU Justification: [Impact] On Jammy 6.8 series, ioprio_set system call does not return correct error value when setting IOPRIO_CLASS_BE to an invalid value. [Fix] - Partially reverting commit <> workaround the issue. + Partially reverting the upstream commit eca2040972b411ec27483bf75dc8b84e730e88ff can workaround the issue. [Test Plan] Run LTP syscall testsuite `ioprio_set03` can sufficiently test the fix. [Where problems could occur] The patch could damage the ioprio_set system call handling further and cause issues with user-space applications that set the I/O priorities. [Other Info] Original bug report: Test failed with 6.5.0-1002.2. Test output: <<<test_start>>> tag=ioprio_set03 stime=1692085364 cmdline="ioprio_set03" contacts="" analysis=exit <<<test_output>>> incrementing stop tst_test.c:1558: TINFO: Timeout per run is 0h 00m 30s ioprio_set03.c:39: TFAIL: ioprio_set IOPRIO_CLASS_BE prio 8 should not work ioprio_set03.c:47: TINFO: tested illegal priority with class NONE ioprio_set03.c:50: TPASS: returned correct error for wrong prio: EINVAL (22) Summary: passed 1 failed 1 broken 0 skipped 0 warnings 0 <<<execution_status>>> initiation_status="ok" duration=0 termination_type=exited termination_id=1 corefile=no cutime=0 cstime=0 <<<test_end>>> Test case: https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/ioprio/ioprio_set03.c ** Description changed: SRU Justification: [Impact] On Jammy 6.8 series, ioprio_set system call does not return correct error value when setting IOPRIO_CLASS_BE to an invalid value. + + On Ubuntu Jammy, since we are using linux-klibc-dev package from 5.15 kernel + the new ioprio level checking logic (added in upstream commit 893e5d32d5832674bcf6465f27958e883b72b346) resided in the 6.8 linux-klibc-dev headers + will not be triggered. [Fix] Partially reverting the upstream commit eca2040972b411ec27483bf75dc8b84e730e88ff can workaround the issue. [Test Plan] Run LTP syscall testsuite `ioprio_set03` can sufficiently test the fix. [Where problems could occur] The patch could damage the ioprio_set system call handling further and cause issues with user-space applications that set the I/O priorities. [Other Info] Original bug report: Test failed with 6.5.0-1002.2. Test output: <<<test_start>>> tag=ioprio_set03 stime=1692085364 cmdline="ioprio_set03" contacts="" analysis=exit <<<test_output>>> incrementing stop tst_test.c:1558: TINFO: Timeout per run is 0h 00m 30s ioprio_set03.c:39: TFAIL: ioprio_set IOPRIO_CLASS_BE prio 8 should not work ioprio_set03.c:47: TINFO: tested illegal priority with class NONE ioprio_set03.c:50: TPASS: returned correct error for wrong prio: EINVAL (22) Summary: passed 1 failed 1 broken 0 skipped 0 warnings 0 <<<execution_status>>> initiation_status="ok" duration=0 termination_type=exited termination_id=1 corefile=no cutime=0 cstime=0 <<<test_end>>> Test case: https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/ioprio/ioprio_set03.c -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2031382 Title: ioprio_set03 in ubuntu_ltp_syscalls failed with J-oem-6.5 (TFAIL: ioprio_set IOPRIO_CLASS_BE prio 8 should not work) Status in ubuntu-kernel-tests: New Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: New Bug description: SRU Justification: [Impact] On Jammy 6.8 series, ioprio_set system call does not return correct error value when setting IOPRIO_CLASS_BE to an invalid value. On Ubuntu Jammy, since we are using linux-klibc-dev package from 5.15 kernel the new ioprio level checking logic (added in upstream commit 893e5d32d5832674bcf6465f27958e883b72b346) resided in the 6.8 linux-klibc-dev headers will not be triggered. [Fix] Partially reverting the upstream commit eca2040972b411ec27483bf75dc8b84e730e88ff can workaround the issue. [Test Plan] Run LTP syscall testsuite `ioprio_set03` can sufficiently test the fix. [Where problems could occur] The patch could damage the ioprio_set system call handling further and cause issues with user-space applications that set the I/O priorities. [Other Info] Original bug report: Test failed with 6.5.0-1002.2. Test output: <<<test_start>>> tag=ioprio_set03 stime=1692085364 cmdline="ioprio_set03" contacts="" analysis=exit <<<test_output>>> incrementing stop tst_test.c:1558: TINFO: Timeout per run is 0h 00m 30s ioprio_set03.c:39: TFAIL: ioprio_set IOPRIO_CLASS_BE prio 8 should not work ioprio_set03.c:47: TINFO: tested illegal priority with class NONE ioprio_set03.c:50: TPASS: returned correct error for wrong prio: EINVAL (22) Summary: passed 1 failed 1 broken 0 skipped 0 warnings 0 <<<execution_status>>> initiation_status="ok" duration=0 termination_type=exited termination_id=1 corefile=no cutime=0 cstime=0 <<<test_end>>> Test case: https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/ioprio/ioprio_set03.c To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/2031382/+subscriptions

[Bug 1968040] Re: [i915] Blanked screen doesn't wake up after locking [drmModeAtomicCommit: Argument invalide] [drmModeAtomicCommit: Invalid argument]

** Tags added: noble -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/1968040 Title: [i915] Blanked screen doesn't wake up after locking [drmModeAtomicCommit: Argument invalide] [drmModeAtomicCommit: Invalid argument] Status in GNOME Shell: New Status in Mutter: New Status in linux package in Ubuntu: Confirmed Status in linux-hwe-5.19 package in Ubuntu: Confirmed Status in linux-hwe-6.8 package in Ubuntu: Confirmed Status in mutter package in Ubuntu: Confirmed Bug description: [ Workaround for 24.04 and later ] Add to /etc/environment:   MUTTER_DEBUG_FORCE_KMS_MODE=simple and then reboot. [ Workaround for 22.04 ] Add to /etc/environment:   MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0 and then reboot. [ Upstream bugs ] https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5098 https://gitlab.gnome.org/GNOME/mutter/-/issues/2268 https://gitlab.gnome.org/GNOME/mutter/-/issues/2749 [ Original report ] (initially reported as a comment on bug #1965085, and split into a separate bug report) After I lock my screen and let it blank, moving the mouse or pressing any key on the keyboard won't wake it up. The only reliable workaround I've found is to press Ctrl+Alt+F1. That's on a fully up-to-date jammy, my hardware is an Intel NUC with a single Samsung monitor connected with a standard HDMI cable. This is a regression that started happening yesterday (2022-04-05) if I can remember correctly (I do apply pending updates at least once daily). ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: gdm3 42.0-1ubuntu2 ProcVersionSignature: Ubuntu 5.15.0-25.25-generic 5.15.30 Uname: Linux 5.15.0-25-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu80 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Wed Apr 6 15:19:30 2022 InstallationDate: Installed on 2020-09-16 (566 days ago) InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Alpha amd64 (20200910) SourcePackage: gdm3 UpgradeStatus: Upgraded to jammy on 2022-03-19 (17 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell/+bug/1968040/+subscriptions

[Bug 2167785] Re: ethernet connection breaks after wakeup

** 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/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 2167799] Re: Can't turn on Bluetooth

** 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/2167799 Title: Can't turn on Bluetooth Status in linux package in Ubuntu: New Bug description: [Expected Behavior] Bluetooth should turn on and be able to discover devices. It works perfectly on the older kernel version [Ubuntu, with Linux: 6.8.0-138]. [Actual Behavior] After the recent September update to kernel [Ubuntu, with Linux: 6.8.0-139], Bluetooth cannot be enabled. The toggle in the settings automatically switches back to "Off". [Steps to Reproduce] 1. Boot into the latest kernel ([6.8.0-139]). 2. Open Settings -> Bluetooth. 3. Try to turn Bluetooth on. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-image-6.8.0-139-generic 6.8.0-139.139 ProcVersionSignature: Ubuntu 6.8.0-139.139-generic 6.8.12 Uname: Linux 6.8.0-139-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.28.3-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: ni 2713 F.... wireplumber /dev/snd/controlC0: ni 2713 F.... wireplumber /dev/snd/seq: ni 2708 F.... pipewire CRDA: N/A CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun Sep 20 20:03:18 2026 InstallationDate: Installed on 2025-11-08 (316 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) MachineType: ASUSTeK COMPUTER INC. ASUS TUF Gaming A15 FA506NFR_FA506NFR ProcFB: 0 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.8.0-139-generic root=UUID=760880b1-41ea-410f-8a9e-bfc6f193138b ro quiet splash pcie_aspm=off vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-6.8.0-139-generic N/A linux-backports-modules-6.8.0-139-generic N/A linux-firmware 20240318.git3b128b60.0ubuntu3.1 SourcePackage: linux UpgradeStatus: Upgraded to noble on 2025-11-08 (316 days ago) dmi.bios.date: 03/21/2024 dmi.bios.release: 5.24 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: FA506NFR.300 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: FA506NFR dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTeK COMPUTER INC. dmi.chassis.version: 1.0 dmi.ec.firmware.release: 3.0 dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvrFA506NFR.300:bd03/21/2024:br5.24:efr3.0:svnASUSTeKCOMPUTERINC.:pnASUSTUFGamingA15FA506NFR_FA506NFR:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnFA506NFR:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:sku: dmi.product.family: ASUS TUF Gaming A15 dmi.product.name: ASUS TUF Gaming A15 FA506NFR_FA506NFR dmi.product.version: 1.0 dmi.sys.vendor: ASUSTeK COMPUTER INC. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167799/+subscriptions

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

I verified this bug and reviewed the patch submitted to linux-fsdevel by Kentaro Shiomi. The root cause is clear: in fs/vboxsf/file.c, vboxsf_write_end() initialises 'nwritten = len' instead of 'copied'. When writing from un- faulted pages (like direct mmap or shared memory used by virtiofsd), copy_page_from_iter_atomic() copies 0 bytes. Because vboxsf_write_end() reports status = len back to VFS, generic_perform_write() thinks the data was written, never calls fault_in_iov_iter_readable(), and enters an endless loop filling the file with zeroes. I tested the patch logic against the Ubuntu kernel trees: 1. Resolute (7.0 / master): Uses the folio write_end signature. 2. Noble 24.04 LTS (6.8): Uses the page write_end signature. 3. Jammy 22.04 LTS (5.15): Same page write_end signature. The patch applies and builds cleanly with zero warnings. I updated the bug description above with the formal SRU justification and a minimal Python reproducer to help the kernel team track this for the next SRU cycle. I am also attaching the DEP-3 formatted patches for both Resolute and Noble. ** Patch added: "DEP-3 patch for Ubuntu 26.04 Resolute (Linux 7.0 / folio write_end)" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167772/+attachment/6001322/+files/lp2167772_vboxsf_resolute_7.0.patch -- 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: Confirmed 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