CVE-2025-39749: rcu: Protect ->defer_qs_iw_pending from data race

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

rcu: Protect ->deferqsiwpending from data race

On kernels built with CONFIGIRQWORK=y, when rcureadunlock() is invoked within an interrupts-disabled region of code [1], it will invoke rcureadunlockspecial(), which uses an irq-work handler to force the system to notice when the RCU read-side critical section actually ends. That end won't happen until interrupts are enabled at the soonest.

In some kernels, such as those booted with rcutree.usesoftirq=y, the irq-work handler is used unconditionally.

The per-CPU rcudata structure's ->deferqsiwpending field is updated by the irq-work handler and is both read and updated by rcureadunlockspecial(). This resulted in the following KCSAN splat:

------------------------------------------------------------------------

BUG: KCSAN: data-race in rcupreemptdeferredqshandler / rcureadunlockspecial

read to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8: rcureadunlockspecial+0x175/0x260 rcureadunlock+0x92/0xa0 rtspinunlock+0x9b/0xc0 localbhenable+0x10d/0x170 localbhenableip+0xfb/0x150 rcudobatch+0x595/0xc40 rcucpukthread+0x4e9/0x830 smpbootthreadfn+0x24d/0x3b0 kthread+0x3bd/0x410 retfromfork+0x35/0x40 retfromforkasm+0x1a/0x30

write to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8: rcupreemptdeferredqshandler+0x1e/0x30 irqworksingle+0xaf/0x160 runirqworkd+0x91/0xc0 smpbootthreadfn+0x24d/0x3b0 kthread+0x3bd/0x410 retfromfork+0x35/0x40 retfromforkasm+0x1a/0x30

no locks held by irqwork/8/88. irq event stamp: 200272 hardirqs last enabled at (200272): [<ffffffffb0f56121>] finishtaskswitch+0x131/0x320 hardirqs last disabled at (200271): [<ffffffffb25c7859>] schedule+0x129/0xd70 softirqs last enabled at (0): [<ffffffffb0ee093f>] copyprocess+0x4df/0x1cc0 softirqs last disabled at (0): [<0000000000000000>] 0x0

------------------------------------------------------------------------

The problem is that irq-work handlers run with interrupts enabled, which means that rcupreemptdeferredqshandler() could be interrupted, and that interrupt handler might contain an RCU read-side critical section, which might invoke rcureadunlockspecial(). In the strict KCSAN mode of operation used by RCU, this constitutes a data race on the ->deferqsiwpending field.

This commit therefore disables interrupts across the portion of the rcupreemptdeferredqshandler() that updates the ->deferqsiwpending field. This suffices because this handler is not a fast path.