CVE-2022-49194

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bcmgenet: Use stronger register read/writes to assure ordering<br /> <br /> GCC12 appears to be much smarter about its dependency tracking and is<br /> aware that the relaxed variants are just normal loads and stores and<br /> this is causing problems like:<br /> <br /> [ 210.074549] ------------[ cut here ]------------<br /> [ 210.079223] NETDEV WATCHDOG: enabcm6e4ei0 (bcmgenet): transmit queue 1 timed out<br /> [ 210.086717] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:529 dev_watchdog+0x234/0x240<br /> [ 210.095044] Modules linked in: genet(E) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat]<br /> [ 210.146561] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110<br /> [ 210.146927] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 5.17.0-rc7G12+ #58<br /> [ 210.153226] CPPC Cpufreq:cppc_scale_freq_workfn: failed to read perf counters<br /> [ 210.161349] Hardware name: Raspberry Pi Foundation Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS EDK2-DEV 02/08/2022<br /> [ 210.161353] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 210.161358] pc : dev_watchdog+0x234/0x240<br /> [ 210.161364] lr : dev_watchdog+0x234/0x240<br /> [ 210.161368] sp : ffff8000080a3a40<br /> [ 210.161370] x29: ffff8000080a3a40 x28: ffffcd425af87000 x27: ffff8000080a3b20<br /> [ 210.205150] x26: ffffcd425aa00000 x25: 0000000000000001 x24: ffffcd425af8ec08<br /> [ 210.212321] x23: 0000000000000100 x22: ffffcd425af87000 x21: ffff55b142688000<br /> [ 210.219491] x20: 0000000000000001 x19: ffff55b1426884c8 x18: ffffffffffffffff<br /> [ 210.226661] x17: 64656d6974203120 x16: 0000000000000001 x15: 6d736e617274203a<br /> [ 210.233831] x14: 2974656e65676d63 x13: ffffcd4259c300d8 x12: ffffcd425b07d5f0<br /> [ 210.241001] x11: 00000000ffffffff x10: ffffcd425b07d5f0 x9 : ffffcd4258bdad9c<br /> [ 210.248171] x8 : 00000000ffffdfff x7 : 000000000000003f x6 : 0000000000000000<br /> [ 210.255341] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000001000<br /> [ 210.262511] x2 : 0000000000001000 x1 : 0000000000000005 x0 : 0000000000000044<br /> [ 210.269682] Call trace:<br /> [ 210.272133] dev_watchdog+0x234/0x240<br /> [ 210.275811] call_timer_fn+0x3c/0x15c<br /> [ 210.279489] __run_timers.part.0+0x288/0x310<br /> [ 210.283777] run_timer_softirq+0x48/0x80<br /> [ 210.287716] __do_softirq+0x128/0x360<br /> [ 210.291392] __irq_exit_rcu+0x138/0x140<br /> [ 210.295243] irq_exit_rcu+0x1c/0x30<br /> [ 210.298745] el1_interrupt+0x38/0x54<br /> [ 210.302334] el1h_64_irq_handler+0x18/0x24<br /> [ 210.306445] el1h_64_irq+0x7c/0x80<br /> [ 210.309857] arch_cpu_idle+0x18/0x2c<br /> [ 210.313445] default_idle_call+0x4c/0x140<br /> [ 210.317470] cpuidle_idle_call+0x14c/0x1a0<br /> [ 210.321584] do_idle+0xb0/0x100<br /> [ 210.324737] cpu_startup_entry+0x30/0x8c<br /> [ 210.328675] secondary_start_kernel+0xe4/0x110<br /> [ 210.333138] __secondary_switched+0x94/0x98<br /> <br /> The assumption when these were relaxed seems to be that device memory<br /> would be mapped non reordering, and that other constructs<br /> (spinlocks/etc) would provide the barriers to assure that packet data<br /> and in memory rings/queues were ordered with respect to device<br /> register reads/writes. This itself seems a bit sketchy, but the real<br /> problem with GCC12 is that it is moving the actual reads/writes around<br /> at will as though they were independent operations when in truth they<br /> are not, but the compiler can&amp;#39;t know that. When looking at the<br /> assembly dumps for many of these routines its possible to see very<br /> clean, but not strictly in program order operations occurring as the<br /> compiler would be free to do if these weren&amp;#39;t actually register<br /> reads/write operations.<br /> <br /> Its possible to suppress the timeout with a liberal bit of dma_mb()&amp;#39;s<br /> sprinkled around but the device still seems unable to reliably<br /> send/receive data. A better plan is to use the safer readl/writel<br /> everywhere.<br /> <br /> Since this partially reverts an older commit, which notes the use of<br /> the relaxed variants for performance reasons. I would suggest that<br /> any performance problems <br /> ---truncated---