Public bug reported: [Impact] Kernel takes a general protection fault in __run_timers while handling remote timer expiry for an idle CPU. The faulting address is 0xdead000000000122 (LIST_POISON2), indicating timer-wheel list corruption in the timer-migration (tmigr) subsystem. The oops is preceded by two WARNs at kernel/workqueue.c:2351 in __queue_work.part.0 from delayed_work_timer_fn. The system becomes unresponsive and reboots (panic=-1). [Environment] * Ubuntu 26.04 * Kernel: 7.0.0-28-generic (Ubuntu 7.0.0-28.28-generic 7.0.12) #28-Ubuntu SMP PREEMPT_DYNAMIC Sun Jun 21 01:01:36 UTC 2026 * Built with gcc 15.2.0-16ubuntu1, ld 2.46 * Ubuntu Core-style install: snapd_recovery_mode=run, immutable /usr, pc-kernel snap, Secure Boot enabled, kernel lockdown active * QEMU/KVM guest, Q35 + ICH9, BIOS 2025.11-3ubuntu7 03/31/2026, 4 vCPUs, ~8 GiB RAM * Boot log confirms timer migration is enabled: "Timer migration: 1 hierarchy levels; 8 children per group; 1 crossnode level" [Steps to Reproduce] 1. Boot the VM into a normal graphical session. 2. Open Chromium (snap) and start a large HTTP(S) download (multi-hundred-MB or larger). 3. Within tens of seconds the two workqueue WARNs fire, followed shortly by the fatal GPF in __run_timers. The machine freezes or auto-reboots. The crashing task in every trace is swapper/N (idle CPU), not Chromium. The download is a workload trigger, not the cause -- it keeps enough delayed-work timers (netfilter conntrack, socket and writeback work, etc.) churning to expose the race in the timer-migration subsystem. No custom reproducer; any workload with sustained delayed-work timer traffic should suffice. [Key Trace -- abbreviated; full oops in attached pstore file] WARNING: kernel/workqueue.c:2351 at __queue_work.part.0+0x190/0x390, CPU#2: swapper/2/0 <IRQ> __queue_work+0x39/0xc0 delayed_work_timer_fn+0x19/0x30 call_timer_fn+0x30/0x170 __run_timers+0x1af/0x2c0 timer_expire_remote+0x52/0x90 tmigr_handle_remote_cpu+0x10e/0x270 tmigr_handle_remote_up+0x115/0x160 tmigr_handle_remote+0xd5/0x140 run_timer_softirq+0xeb/0x100 handle_softirqs+0xe1/0x360 __irq_exit_rcu+0x100/0x120 sysvec_apic_timer_interrupt+0x9f/0xd0 Oops: general protection fault, probably for non-canonical address 0xdead00000000012a: 0000 [#1] SMP NOPTI RIP: 0010:__run_timers+0x1e0/0x2c0 RAX: dead000000000122 R12: dead000000000122 Call Trace: <IRQ> timer_expire_remote+0x52/0x90 tmigr_handle_remote_cpu+0x10e/0x270 tmigr_handle_remote_up+0x115/0x160 tmigr_handle_remote+0xd5/0x140 run_timer_softirq+0xeb/0x100 Kernel taint at oops: G W (from the preceding workqueue WARNs only; no out-of-tree modules). [Likely Upstream Match] Two open syzbot reports appear to describe the same bug (both against 7.0 / net-7.0-rc1, both faulting in the timer-wheel expiry path with a LIST_POISON2 dereference in the range 0xdead000000000128..0xdead00000000012f): * syzbot+e53e8221436aa398a8be -- "general protection fault in __run_timers (4)", reported 2026-08-04, subsystem tag netfilter, faulting in detach_timer -> expire_timers -> __run_timers. * syzbot+1a48e52497e1769b08de -- "general protection fault in detach_timer (2)", reported 2026-02-20 in ktimers/0. Neither has a public reproducer. If Ubuntu backports the eventual upstream fix this bug should close by SRU. [Workaround] Setting kernel.timer_migration=0 via /etc/sysctl.d/99-timer-migration.conf reduces cross-CPU timer placement and, in local testing, prevents the crash under the same download workload. This is mitigation, not fix -- the underlying tmigr race remains. [Other Info] * ProblemType: Bug * DistroRelease: Ubuntu 26.04 * Package: linux-image-7.0.0-28-generic 7.0.0-28.28 * Regression: unknown (no prior 7.0.x kernel tested on this install) * Reproducible: yes, on demand under the workload above [Attachments] * /var/lib/systemd/pstore/dmesg-efi-* -- full oops recorded by the kernel before reboot * Full boot dmesg (journalctl -k -b) * uname -a * snap list --all pc-kernel * snap info pc-kernel * cat /proc/cmdline ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-28-generic (not installed) ProcVersionSignature: Ubuntu 7.0.0-28.28-generic 7.0.12 Uname: Linux 7.0.0-28-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: user 3023 F.... wireplumber /dev/snd/seq: user 3016 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Mon Aug 31 14:22:44 2026 Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 0409:55aa NEC Corp. Hub Bus 001 Device 003: ID 0627:0001 Adomax Technology Co., Ltd QEMU Tablet Bus 001 Device 005: ID 1050:0407 Yubico.com Yubikey 4/5 OTP+U2F+CCID Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub MachineType: QEMU Standard PC (Q35 + ICH9, 2009) ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color ProcFB: 0 virtio_gpudrmfb ProcKernelCmdLine: snapd_recovery_mode=run console=ttyS0,115200n8 console=tty1 panic=-1 quiet splash snapd.xkb="us,pc105,," RfKill: SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/31/2026 dmi.bios.release: 0.0 dmi.bios.vendor: Ubuntu distribution of EDK II dmi.bios.version: 2025.11-3ubuntu7 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-q35-10.2 dmi.modalias: dmi:bvnUbuntudistributionofEDKII:bvr2025.11-3ubuntu7:bd03/31/2026:br0.0:svnQEMU:pnStandardPC(Q35+ICH9,2009):pvrpc-q35-10.2:cvnQEMU:ct1:cvrpc-q35-10.2:sku:pfa: dmi.product.name: Standard PC (Q35 + ICH9, 2009) dmi.product.version: pc-q35-10.2 dmi.sys.vendor: QEMU ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug resolute -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2165930 Title: Kernel oops (GPF) in __run_timers via tmigr_handle_remote on 7.0.0-28-generic under network load Status in linux package in Ubuntu: New Bug description: [Impact] Kernel takes a general protection fault in __run_timers while handling remote timer expiry for an idle CPU. The faulting address is 0xdead000000000122 (LIST_POISON2), indicating timer-wheel list corruption in the timer-migration (tmigr) subsystem. The oops is preceded by two WARNs at kernel/workqueue.c:2351 in __queue_work.part.0 from delayed_work_timer_fn. The system becomes unresponsive and reboots (panic=-1). [Environment] * Ubuntu 26.04 * Kernel: 7.0.0-28-generic (Ubuntu 7.0.0-28.28-generic 7.0.12) #28-Ubuntu SMP PREEMPT_DYNAMIC Sun Jun 21 01:01:36 UTC 2026 * Built with gcc 15.2.0-16ubuntu1, ld 2.46 * Ubuntu Core-style install: snapd_recovery_mode=run, immutable /usr, pc-kernel snap, Secure Boot enabled, kernel lockdown active * QEMU/KVM guest, Q35 + ICH9, BIOS 2025.11-3ubuntu7 03/31/2026, 4 vCPUs, ~8 GiB RAM * Boot log confirms timer migration is enabled: "Timer migration: 1 hierarchy levels; 8 children per group; 1 crossnode level" [Steps to Reproduce] 1. Boot the VM into a normal graphical session. 2. Open Chromium (snap) and start a large HTTP(S) download (multi-hundred-MB or larger). 3. Within tens of seconds the two workqueue WARNs fire, followed shortly by the fatal GPF in __run_timers. The machine freezes or auto-reboots. The crashing task in every trace is swapper/N (idle CPU), not Chromium. The download is a workload trigger, not the cause -- it keeps enough delayed-work timers (netfilter conntrack, socket and writeback work, etc.) churning to expose the race in the timer-migration subsystem. No custom reproducer; any workload with sustained delayed-work timer traffic should suffice. [Key Trace -- abbreviated; full oops in attached pstore file] WARNING: kernel/workqueue.c:2351 at __queue_work.part.0+0x190/0x390, CPU#2: swapper/2/0 <IRQ> __queue_work+0x39/0xc0 delayed_work_timer_fn+0x19/0x30 call_timer_fn+0x30/0x170 __run_timers+0x1af/0x2c0 timer_expire_remote+0x52/0x90 tmigr_handle_remote_cpu+0x10e/0x270 tmigr_handle_remote_up+0x115/0x160 tmigr_handle_remote+0xd5/0x140 run_timer_softirq+0xeb/0x100 handle_softirqs+0xe1/0x360 __irq_exit_rcu+0x100/0x120 sysvec_apic_timer_interrupt+0x9f/0xd0 Oops: general protection fault, probably for non-canonical address 0xdead00000000012a: 0000 [#1] SMP NOPTI RIP: 0010:__run_timers+0x1e0/0x2c0 RAX: dead000000000122 R12: dead000000000122 Call Trace: <IRQ> timer_expire_remote+0x52/0x90 tmigr_handle_remote_cpu+0x10e/0x270 tmigr_handle_remote_up+0x115/0x160 tmigr_handle_remote+0xd5/0x140 run_timer_softirq+0xeb/0x100 Kernel taint at oops: G W (from the preceding workqueue WARNs only; no out-of-tree modules). [Likely Upstream Match] Two open syzbot reports appear to describe the same bug (both against 7.0 / net-7.0-rc1, both faulting in the timer-wheel expiry path with a LIST_POISON2 dereference in the range 0xdead000000000128..0xdead00000000012f): * syzbot+e53e8221436aa398a8be -- "general protection fault in __run_timers (4)", reported 2026-08-04, subsystem tag netfilter, faulting in detach_timer -> expire_timers -> __run_timers. * syzbot+1a48e52497e1769b08de -- "general protection fault in detach_timer (2)", reported 2026-02-20 in ktimers/0. Neither has a public reproducer. If Ubuntu backports the eventual upstream fix this bug should close by SRU. [Workaround] Setting kernel.timer_migration=0 via /etc/sysctl.d/99-timer-migration.conf reduces cross-CPU timer placement and, in local testing, prevents the crash under the same download workload. This is mitigation, not fix -- the underlying tmigr race remains. [Other Info] * ProblemType: Bug * DistroRelease: Ubuntu 26.04 * Package: linux-image-7.0.0-28-generic 7.0.0-28.28 * Regression: unknown (no prior 7.0.x kernel tested on this install) * Reproducible: yes, on demand under the workload above [Attachments] * /var/lib/systemd/pstore/dmesg-efi-* -- full oops recorded by the kernel before reboot * Full boot dmesg (journalctl -k -b) * uname -a * snap list --all pc-kernel * snap info pc-kernel * cat /proc/cmdline ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-28-generic (not installed) ProcVersionSignature: Ubuntu 7.0.0-28.28-generic 7.0.12 Uname: Linux 7.0.0-28-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: user 3023 F.... wireplumber /dev/snd/seq: user 3016 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Mon Aug 31 14:22:44 2026 Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 0409:55aa NEC Corp. Hub Bus 001 Device 003: ID 0627:0001 Adomax Technology Co., Ltd QEMU Tablet Bus 001 Device 005: ID 1050:0407 Yubico.com Yubikey 4/5 OTP+U2F+CCID Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub MachineType: QEMU Standard PC (Q35 + ICH9, 2009) ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color ProcFB: 0 virtio_gpudrmfb ProcKernelCmdLine: snapd_recovery_mode=run console=ttyS0,115200n8 console=tty1 panic=-1 quiet splash snapd.xkb="us,pc105,," RfKill: SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/31/2026 dmi.bios.release: 0.0 dmi.bios.vendor: Ubuntu distribution of EDK II dmi.bios.version: 2025.11-3ubuntu7 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-q35-10.2 dmi.modalias: dmi:bvnUbuntudistributionofEDKII:bvr2025.11-3ubuntu7:bd03/31/2026:br0.0:svnQEMU:pnStandardPC(Q35+ICH9,2009):pvrpc-q35-10.2:cvnQEMU:ct1:cvrpc-q35-10.2:sku:pfa: dmi.product.name: Standard PC (Q35 + ICH9, 2009) dmi.product.version: pc-q35-10.2 dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2165930/+subscriptions
Комментариев нет:
Отправить комментарий