CVE-2022-49540

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcu-tasks: Fix race in schedule and flush work<br /> <br /> While booting secondary CPUs, cpus_read_[lock/unlock] is not keeping<br /> online cpumask stable. The transient online mask results in below<br /> calltrace.<br /> <br /> [ 0.324121] CPU1: Booted secondary processor 0x0000000001 [0x410fd083]<br /> [ 0.346652] Detected PIPT I-cache on CPU2<br /> [ 0.347212] CPU2: Booted secondary processor 0x0000000002 [0x410fd083]<br /> [ 0.377255] Detected PIPT I-cache on CPU3<br /> [ 0.377823] CPU3: Booted secondary processor 0x0000000003 [0x410fd083]<br /> [ 0.379040] ------------[ cut here ]------------<br /> [ 0.383662] WARNING: CPU: 0 PID: 10 at kernel/workqueue.c:3084 __flush_work+0x12c/0x138<br /> [ 0.384850] Modules linked in:<br /> [ 0.385403] CPU: 0 PID: 10 Comm: rcu_tasks_rude_ Not tainted 5.17.0-rc3-v8+ #13<br /> [ 0.386473] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)<br /> [ 0.387289] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 0.388308] pc : __flush_work+0x12c/0x138<br /> [ 0.388970] lr : __flush_work+0x80/0x138<br /> [ 0.389620] sp : ffffffc00aaf3c60<br /> [ 0.390139] x29: ffffffc00aaf3d20 x28: ffffffc009c16af0 x27: ffffff80f761df48<br /> [ 0.391316] x26: 0000000000000004 x25: 0000000000000003 x24: 0000000000000100<br /> [ 0.392493] x23: ffffffffffffffff x22: ffffffc009c16b10 x21: ffffffc009c16b28<br /> [ 0.393668] x20: ffffffc009e53861 x19: ffffff80f77fbf40 x18: 00000000d744fcc9<br /> [ 0.394842] x17: 000000000000000b x16: 00000000000001c2 x15: ffffffc009e57550<br /> [ 0.396016] x14: 0000000000000000 x13: ffffffffffffffff x12: 0000000100000000<br /> [ 0.397190] x11: 0000000000000462 x10: ffffff8040258008 x9 : 0000000100000000<br /> [ 0.398364] x8 : 0000000000000000 x7 : ffffffc0093c8bf4 x6 : 0000000000000000<br /> [ 0.399538] x5 : 0000000000000000 x4 : ffffffc00a976e40 x3 : ffffffc00810444c<br /> [ 0.400711] x2 : 0000000000000004 x1 : 0000000000000000 x0 : 0000000000000000<br /> [ 0.401886] Call trace:<br /> [ 0.402309] __flush_work+0x12c/0x138<br /> [ 0.402941] schedule_on_each_cpu+0x228/0x278<br /> [ 0.403693] rcu_tasks_rude_wait_gp+0x130/0x144<br /> [ 0.404502] rcu_tasks_kthread+0x220/0x254<br /> [ 0.405264] kthread+0x174/0x1ac<br /> [ 0.405837] ret_from_fork+0x10/0x20<br /> [ 0.406456] irq event stamp: 102<br /> [ 0.406966] hardirqs last enabled at (101): [] _raw_spin_unlock_irq+0x78/0xb4<br /> [ 0.408304] hardirqs last disabled at (102): [] el1_dbg+0x24/0x5c<br /> [ 0.409410] softirqs last enabled at (54): [] local_bh_enable+0xc/0x2c<br /> [ 0.410645] softirqs last disabled at (50): [] local_bh_disable+0xc/0x2c<br /> [ 0.411890] ---[ end trace 0000000000000000 ]---<br /> [ 0.413000] smp: Brought up 1 node, 4 CPUs<br /> [ 0.413762] SMP: Total of 4 processors activated.<br /> [ 0.414566] CPU features: detected: 32-bit EL0 Support<br /> [ 0.415414] CPU features: detected: 32-bit EL1 Support<br /> [ 0.416278] CPU features: detected: CRC32 instructions<br /> [ 0.447021] Callback from call_rcu_tasks_rude() invoked.<br /> [ 0.506693] Callback from call_rcu_tasks() invoked.<br /> <br /> This commit therefore fixes this issue by applying a single-CPU<br /> optimization to the RCU Tasks Rude grace-period process. The key point<br /> here is that the purpose of this RCU flavor is to force a schedule on<br /> each online CPU since some past event. But the rcu_tasks_rude_wait_gp()<br /> function runs in the context of the RCU Tasks Rude&amp;#39;s grace-period kthread,<br /> so there must already have been a context switch on the current CPU since<br /> the call to either synchronize_rcu_tasks_rude() or call_rcu_tasks_rude().<br /> So if there is only a single CPU online, RCU Tasks Rude&amp;#39;s grace-period<br /> kthread does not need to anything at all.<br /> <br /> It turns out that the rcu_tasks_rude_wait_gp() function&amp;#39;s call to<br /> schedule_on_each_cpu() causes problems during early boot. During that<br /> time, there is only one online CPU, namely the boot CPU. Therefore,<br /> applying this single-CPU optimization fixes early-boot instances of<br /> this problem.