CVE-2026-43385

In the Linux kernel, the following vulnerability has been resolved:

net: Fix rcu_tasks stall in threaded busypoll

I was debugging a NIC driver when I noticed that when I enable threaded busypoll, bpftrace hangs when starting up. dmesg showed:

rcutaskswaitgp: rcutasks grace period number 85 (since boot) is 10658 jiffies old. rcutaskswaitgp: rcutasks grace period number 85 (since boot) is 40793 jiffies old. rcutaskswaitgp: rcutasks grace period number 85 (since boot) is 131273 jiffies old. rcutaskswaitgp: rcutasks grace period number 85 (since boot) is 402058 jiffies old. INFO: rcutasks detected stalls on tasks: 00000000769f52cd: .N nvcsw: 2/2 holdout: 1 idlecpu: -1/64 task:napi/eth2-8265 state:R running task stack:0 pid:48300 tgid:48300 ppid:2 taskflags:0x208040 flags:0x00004000 Call Trace: <TASK> ? napithreadedpollloop+0x27c/0x2c0 ? __pfxnapithreaded_poll+0x10/0x10 ? napithreadedpoll+0x26/0x80 ? kthread+0xfa/0x240 ? __pfxkthread+0x10/0x10 ? retfrom_fork+0x31/0x50 ? __pfxkthread+0x10/0x10 ? retfromforkasm+0x1a/0x30 </TASK>

The cause is that in threaded busypoll, the main loop is in napithreadedpoll rather than napithreadedpollloop, where the latter rarely iterates more than once within its loop. For rcusoftirqqsperiodic inside napithreadedpollloop to report its qs state, the lastqs must be 100ms behind, and this can't happen because napithreadedpollloop rarely iterates in threaded busypoll, and each time napithreadedpollloop is called last_qs is reset to latest jiffies.

This patch changes so that in threaded busypoll, lastqs is saved in the outer napithreadedpoll, and whether busypolllastqs is NULL indicates whether napithreadedpollloop is called for busypoll. This way lastqs would not reset to latest jiffies on each invocation of napithreadedpoll_loop.