Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: felix: don&amp;#39;t use devres for mdiobus<br /> <br /> As explained in commits:<br /> 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres")<br /> 5135e96a3dd2 ("net: dsa: don&amp;#39;t allocate the slave_mii_bus using devres")<br /> <br /> mdiobus_free() will panic when called from devm_mdiobus_free() shutdown) do not apply. But there is one more which<br /> applies here.<br /> <br /> If the DSA master itself is on a bus that calls -&gt;remove from -&gt;shutdown<br /> (like dpaa2-eth, which is on the fsl-mc bus), there is a device link<br /> between the switch and the DSA master, and device_links_unbind_consumers()<br /> will unbind the felix switch driver on shutdown.<br /> <br /> So the same treatment must be applied to all DSA switch drivers, which<br /> is: either use devres for both the mdiobus allocation and registration,<br /> or don&amp;#39;t use devres at all.<br /> <br /> The felix driver has the code structure in place for orderly mdiobus<br /> removal, so just replace devm_mdiobus_alloc_size() with the non-devres<br /> variant, and add manual free where necessary, to ensure that we don&amp;#39;t<br /> let devres free a still-registered bus.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: seville: register the mdiobus under devres<br /> <br /> As explained in commits:<br /> 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres")<br /> 5135e96a3dd2 ("net: dsa: don&amp;#39;t allocate the slave_mii_bus using devres")<br /> <br /> mdiobus_free() will panic when called from devm_mdiobus_free() shutdown) do not apply. But there is one more which<br /> applies here.<br /> <br /> If the DSA master itself is on a bus that calls -&gt;remove from -&gt;shutdown<br /> (like dpaa2-eth, which is on the fsl-mc bus), there is a device link<br /> between the switch and the DSA master, and device_links_unbind_consumers()<br /> will unbind the seville switch driver on shutdown.<br /> <br /> So the same treatment must be applied to all DSA switch drivers, which<br /> is: either use devres for both the mdiobus allocation and registration,<br /> or don&amp;#39;t use devres at all.<br /> <br /> The seville driver has a code structure that could accommodate both the<br /> mdiobus_unregister and mdiobus_free calls, but it has an external<br /> dependency upon mscc_miim_setup() from mdio-mscc-miim.c, which calls<br /> devm_mdiobus_alloc_size() on its behalf. So rather than restructuring<br /> that, and exporting yet one more symbol mscc_miim_teardown(), let&amp;#39;s work<br /> with devres and replace of_mdiobus_register with the devres variant.<br /> When we use all-devres, we can ensure that devres doesn&amp;#39;t free a<br /> still-registered bus (it either runs both callbacks, or none).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: bcm_sf2: don&amp;#39;t use devres for mdiobus<br /> <br /> As explained in commits:<br /> 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres")<br /> 5135e96a3dd2 ("net: dsa: don&amp;#39;t allocate the slave_mii_bus using devres")<br /> <br /> mdiobus_free() will panic when called from devm_mdiobus_free() shutdown) do not apply. But there is one more which<br /> applies here.<br /> <br /> If the DSA master itself is on a bus that calls -&gt;remove from -&gt;shutdown<br /> (like dpaa2-eth, which is on the fsl-mc bus), there is a device link<br /> between the switch and the DSA master, and device_links_unbind_consumers()<br /> will unbind the bcm_sf2 switch driver on shutdown.<br /> <br /> So the same treatment must be applied to all DSA switch drivers, which<br /> is: either use devres for both the mdiobus allocation and registration,<br /> or don&amp;#39;t use devres at all.<br /> <br /> The bcm_sf2 driver has the code structure in place for orderly mdiobus<br /> removal, so just replace devm_mdiobus_alloc() with the non-devres<br /> variant, and add manual free where necessary, to ensure that we don&amp;#39;t<br /> let devres free a still-registered bus.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> SUNRPC: lock against -&gt;sock changing during sysfs read<br /> <br /> -&gt;sock can be set to NULL asynchronously unless -&gt;recv_mutex is held.<br /> So it is important to hold that mutex. Otherwise a sysfs read can<br /> trigger an oops.<br /> Commit 17f09d3f619a ("SUNRPC: Check if the xprt is connected before<br /> handling sysfs reads") appears to attempt to fix this problem, but it<br /> only narrows the race window.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: ar9331: register the mdiobus under devres<br /> <br /> As explained in commits:<br /> 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres")<br /> 5135e96a3dd2 ("net: dsa: don&amp;#39;t allocate the slave_mii_bus using devres")<br /> <br /> mdiobus_free() will panic when called from devm_mdiobus_free() shutdown) do not apply. But there is one more which applies here.<br /> <br /> If the DSA master itself is on a bus that calls -&gt;remove from -&gt;shutdown<br /> (like dpaa2-eth, which is on the fsl-mc bus), there is a device link<br /> between the switch and the DSA master, and device_links_unbind_consumers()<br /> will unbind the ar9331 switch driver on shutdown.<br /> <br /> So the same treatment must be applied to all DSA switch drivers, which<br /> is: either use devres for both the mdiobus allocation and registration,<br /> or don&amp;#39;t use devres at all.<br /> <br /> The ar9331 driver doesn&amp;#39;t have a complex code structure for mdiobus<br /> removal, so just replace of_mdiobus_register with the devres variant in<br /> order to be all-devres and ensure that we don&amp;#39;t free a still-registered<br /> bus.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: mv88e6xxx: don&amp;#39;t use devres for mdiobus<br /> <br /> As explained in commits:<br /> 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres")<br /> 5135e96a3dd2 ("net: dsa: don&amp;#39;t allocate the slave_mii_bus using devres")<br /> <br /> mdiobus_free() will panic when called from devm_mdiobus_free() shutdown) do not apply. But there is one more which applies here.<br /> <br /> If the DSA master itself is on a bus that calls -&gt;remove from -&gt;shutdown<br /> (like dpaa2-eth, which is on the fsl-mc bus), there is a device link<br /> between the switch and the DSA master, and device_links_unbind_consumers()<br /> will unbind the Marvell switch driver on shutdown.<br /> <br /> systemd-shutdown[1]: Powering off.<br /> mv88e6085 0x0000000008b96000:00 sw_gl0: Link is Down<br /> fsl-mc dpbp.9: Removing from iommu group 7<br /> fsl-mc dpbp.8: Removing from iommu group 7<br /> ------------[ cut here ]------------<br /> kernel BUG at drivers/net/phy/mdio_bus.c:677!<br /> Internal error: Oops - BUG: 0 [#1] PREEMPT SMP<br /> Modules linked in:<br /> CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 5.16.5-00040-gdc05f73788e5 #15<br /> pc : mdiobus_free+0x44/0x50<br /> lr : devm_mdiobus_free+0x10/0x20<br /> Call trace:<br /> mdiobus_free+0x44/0x50<br /> devm_mdiobus_free+0x10/0x20<br /> devres_release_all+0xa0/0x100<br /> __device_release_driver+0x190/0x220<br /> device_release_driver_internal+0xac/0xb0<br /> device_links_unbind_consumers+0xd4/0x100<br /> __device_release_driver+0x4c/0x220<br /> device_release_driver_internal+0xac/0xb0<br /> device_links_unbind_consumers+0xd4/0x100<br /> __device_release_driver+0x94/0x220<br /> device_release_driver+0x28/0x40<br /> bus_remove_device+0x118/0x124<br /> device_del+0x174/0x420<br /> fsl_mc_device_remove+0x24/0x40<br /> __fsl_mc_device_remove+0xc/0x20<br /> device_for_each_child+0x58/0xa0<br /> dprc_remove+0x90/0xb0<br /> fsl_mc_driver_remove+0x20/0x5c<br /> __device_release_driver+0x21c/0x220<br /> device_release_driver+0x28/0x40<br /> bus_remove_device+0x118/0x124<br /> device_del+0x174/0x420<br /> fsl_mc_bus_remove+0x80/0x100<br /> fsl_mc_bus_shutdown+0xc/0x1c<br /> platform_shutdown+0x20/0x30<br /> device_shutdown+0x154/0x330<br /> kernel_power_off+0x34/0x6c<br /> __do_sys_reboot+0x15c/0x250<br /> __arm64_sys_reboot+0x20/0x30<br /> invoke_syscall.constprop.0+0x4c/0xe0<br /> do_el0_svc+0x4c/0x150<br /> el0_svc+0x24/0xb0<br /> el0t_64_sync_handler+0xa8/0xb0<br /> el0t_64_sync+0x178/0x17c<br /> <br /> So the same treatment must be applied to all DSA switch drivers, which<br /> is: either use devres for both the mdiobus allocation and registration,<br /> or don&amp;#39;t use devres at all.<br /> <br /> The Marvell driver already has a good structure for mdiobus removal, so<br /> just plug in mdiobus_free and get rid of devres.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: take care of mixed splice()/sendmsg(MSG_ZEROCOPY) case<br /> <br /> syzbot found that mixing sendpage() and sendmsg(MSG_ZEROCOPY)<br /> calls over the same TCP socket would again trigger the<br /> infamous warning in inet_sock_destruct()<br /> <br /> WARN_ON(sk_forward_alloc_get(sk));<br /> <br /> While Talal took into account a mix of regular copied data<br /> and MSG_ZEROCOPY one in the same skb, the sendpage() path<br /> has been forgotten.<br /> <br /> We want the charging to happen for sendpage(), because<br /> pages could be coming from a pipe. What is missing is the<br /> downgrading of pure zerocopy status to make sure<br /> sk_forward_alloc will stay synced.<br /> <br /> Add tcp_downgrade_zcopy_pure() helper so that we can<br /> use it from the two callers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: stm32: fix a refcount leak in stm32_usbphyc_pll_enable()<br /> <br /> This error path needs to decrement "usbphyc-&gt;n_pll_cons.counter" before<br /> returning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: nSVM: fix potential NULL derefernce on nested migration<br /> <br /> Turns out that due to review feedback and/or rebases<br /> I accidentally moved the call to nested_svm_load_cr3 to be too early,<br /> before the NPT is enabled, which is very wrong to do.<br /> <br /> KVM can&amp;#39;t even access guest memory at that point as nested NPT<br /> is needed for that, and of course it won&amp;#39;t initialize the walk_mmu,<br /> which is main issue the patch was addressing.<br /> <br /> Fix this for real.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ieee802154: at86rf230: Stop leaking skb&amp;#39;s<br /> <br /> Upon error the ieee802154_xmit_complete() helper is not called. Only<br /> ieee802154_wake_queue() is called manually. In the Tx case we then leak<br /> the skb structure.<br /> <br /> Free the skb structure upon error before returning when appropriate.<br /> <br /> As the &amp;#39;is_tx = 0&amp;#39; cannot be moved in the complete handler because of a<br /> possible race between the delay in switching to STATE_RX_AACK_ON and a<br /> new interrupt, we introduce an intermediate &amp;#39;was_tx&amp;#39; boolean just for<br /> this purpose.<br /> <br /> There is no Fixes tag applying here, many changes have been made on this<br /> area and the issue kind of always existed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> parisc: Fix data TLB miss in sba_unmap_sg<br /> <br /> Rolf Eike Beer reported the following bug:<br /> <br /> [1274934.746891] Bad Address (null pointer deref?): Code=15 (Data TLB miss fault) at addr 0000004140000018<br /> [1274934.746891] CPU: 3 PID: 5549 Comm: cmake Not tainted 5.15.4-gentoo-parisc64 #4<br /> [1274934.746891] Hardware name: 9000/785/C8000<br /> [1274934.746891]<br /> [1274934.746891] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI<br /> [1274934.746891] PSW: 00001000000001001111111000001110 Not tainted<br /> [1274934.746891] r00-03 000000ff0804fe0e 0000000040bc9bc0 00000000406760e4 0000004140000000<br /> [1274934.746891] r04-07 0000000040b693c0 0000004140000000 000000004a2b08b0 0000000000000001<br /> [1274934.746891] r08-11 0000000041f98810 0000000000000000 000000004a0a7000 0000000000000001<br /> [1274934.746891] r12-15 0000000040bddbc0 0000000040c0cbc0 0000000040bddbc0 0000000040bddbc0<br /> [1274934.746891] r16-19 0000000040bde3c0 0000000040bddbc0 0000000040bde3c0 0000000000000007<br /> [1274934.746891] r20-23 0000000000000006 000000004a368950 0000000000000000 0000000000000001<br /> [1274934.746891] r24-27 0000000000001fff 000000000800000e 000000004a1710f0 0000000040b693c0<br /> [1274934.746891] r28-31 0000000000000001 0000000041f988b0 0000000041f98840 000000004a171118<br /> [1274934.746891] sr00-03 00000000066e5800 0000000000000000 0000000000000000 00000000066e5800<br /> [1274934.746891] sr04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000<br /> [1274934.746891]<br /> [1274934.746891] IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000406760e8 00000000406760ec<br /> [1274934.746891] IIR: 48780030 ISR: 0000000000000000 IOR: 0000004140000018<br /> [1274934.746891] CPU: 3 CR30: 00000040e3a9c000 CR31: ffffffffffffffff<br /> [1274934.746891] ORIG_R28: 0000000040acdd58<br /> [1274934.746891] IAOQ[0]: sba_unmap_sg+0xb0/0x118<br /> [1274934.746891] IAOQ[1]: sba_unmap_sg+0xb4/0x118<br /> [1274934.746891] RP(r2): sba_unmap_sg+0xac/0x118<br /> [1274934.746891] Backtrace:<br /> [1274934.746891] [] dma_unmap_sg_attrs+0x6c/0x70<br /> [1274934.746891] [] scsi_dma_unmap+0x54/0x60<br /> [1274934.746891] [] mptscsih_io_done+0x150/0xd70<br /> [1274934.746891] [] mpt_interrupt+0x168/0xa68<br /> [1274934.746891] [] __handle_irq_event_percpu+0xc8/0x278<br /> [1274934.746891] [] handle_irq_event_percpu+0x3c/0xd8<br /> [1274934.746891] [] handle_percpu_irq+0xb4/0xf0<br /> [1274934.746891] [] generic_handle_irq+0x50/0x70<br /> [1274934.746891] [] call_on_stack+0x18/0x24<br /> [1274934.746891]<br /> [1274934.746891] Kernel panic - not syncing: Bad Address (null pointer deref?)<br /> <br /> The bug is caused by overrunning the sglist and incorrectly testing<br /> sg_dma_len(sglist) before nents. Normally this doesn&amp;#39;t cause a crash,<br /> but in this case sglist crossed a page boundary. This occurs in the<br /> following code:<br /> <br /> while (sg_dma_len(sglist) &amp;&amp; nents--) {<br /> <br /> The fix is simply to test nents first and move the decrement of nents<br /> into the loop.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu: Fix potential use-after-free during probe<br /> <br /> Kasan has reported the following use after free on dev-&gt;iommu.<br /> when a device probe fails and it is in process of freeing dev-&gt;iommu<br /> in dev_iommu_free function, a deferred_probe_work_func runs in parallel<br /> and tries to access dev-&gt;iommu-&gt;fwspec in of_iommu_configure path thus<br /> causing use after free.<br /> <br /> BUG: KASAN: use-after-free in of_iommu_configure+0xb4/0x4a4<br /> Read of size 8 at addr ffffff87a2f1acb8 by task kworker/u16:2/153<br /> <br /> Workqueue: events_unbound deferred_probe_work_func<br /> Call trace:<br /> dump_backtrace+0x0/0x33c<br /> show_stack+0x18/0x24<br /> dump_stack_lvl+0x16c/0x1e0<br /> print_address_description+0x84/0x39c<br /> __kasan_report+0x184/0x308<br /> kasan_report+0x50/0x78<br /> __asan_load8+0xc0/0xc4<br /> of_iommu_configure+0xb4/0x4a4<br /> of_dma_configure_id+0x2fc/0x4d4<br /> platform_dma_configure+0x40/0x5c<br /> really_probe+0x1b4/0xb74<br /> driver_probe_device+0x11c/0x228<br /> __device_attach_driver+0x14c/0x304<br /> bus_for_each_drv+0x124/0x1b0<br /> __device_attach+0x25c/0x334<br /> device_initial_probe+0x24/0x34<br /> bus_probe_device+0x78/0x134<br /> deferred_probe_work_func+0x130/0x1a8<br /> process_one_work+0x4c8/0x970<br /> worker_thread+0x5c8/0xaec<br /> kthread+0x1f8/0x220<br /> ret_from_fork+0x10/0x18<br /> <br /> Allocated by task 1:<br /> ____kasan_kmalloc+0xd4/0x114<br /> __kasan_kmalloc+0x10/0x1c<br /> kmem_cache_alloc_trace+0xe4/0x3d4<br /> __iommu_probe_device+0x90/0x394<br /> probe_iommu_group+0x70/0x9c<br /> bus_for_each_dev+0x11c/0x19c<br /> bus_iommu_probe+0xb8/0x7d4<br /> bus_set_iommu+0xcc/0x13c<br /> arm_smmu_bus_init+0x44/0x130 [arm_smmu]<br /> arm_smmu_device_probe+0xb88/0xc54 [arm_smmu]<br /> platform_drv_probe+0xe4/0x13c<br /> really_probe+0x2c8/0xb74<br /> driver_probe_device+0x11c/0x228<br /> device_driver_attach+0xf0/0x16c<br /> __driver_attach+0x80/0x320<br /> bus_for_each_dev+0x11c/0x19c<br /> driver_attach+0x38/0x48<br /> bus_add_driver+0x1dc/0x3a4<br /> driver_register+0x18c/0x244<br /> __platform_driver_register+0x88/0x9c<br /> init_module+0x64/0xff4 [arm_smmu]<br /> do_one_initcall+0x17c/0x2f0<br /> do_init_module+0xe8/0x378<br /> load_module+0x3f80/0x4a40<br /> __se_sys_finit_module+0x1a0/0x1e4<br /> __arm64_sys_finit_module+0x44/0x58<br /> el0_svc_common+0x100/0x264<br /> do_el0_svc+0x38/0xa4<br /> el0_svc+0x20/0x30<br /> el0_sync_handler+0x68/0xac<br /> el0_sync+0x160/0x180<br /> <br /> Freed by task 1:<br /> kasan_set_track+0x4c/0x84<br /> kasan_set_free_info+0x28/0x4c<br /> ____kasan_slab_free+0x120/0x15c<br /> __kasan_slab_free+0x18/0x28<br /> slab_free_freelist_hook+0x204/0x2fc<br /> kfree+0xfc/0x3a4<br /> __iommu_probe_device+0x284/0x394<br /> probe_iommu_group+0x70/0x9c<br /> bus_for_each_dev+0x11c/0x19c<br /> bus_iommu_probe+0xb8/0x7d4<br /> bus_set_iommu+0xcc/0x13c<br /> arm_smmu_bus_init+0x44/0x130 [arm_smmu]<br /> arm_smmu_device_probe+0xb88/0xc54 [arm_smmu]<br /> platform_drv_probe+0xe4/0x13c<br /> really_probe+0x2c8/0xb74<br /> driver_probe_device+0x11c/0x228<br /> device_driver_attach+0xf0/0x16c<br /> __driver_attach+0x80/0x320<br /> bus_for_each_dev+0x11c/0x19c<br /> driver_attach+0x38/0x48<br /> bus_add_driver+0x1dc/0x3a4<br /> driver_register+0x18c/0x244<br /> __platform_driver_register+0x88/0x9c<br /> init_module+0x64/0xff4 [arm_smmu]<br /> do_one_initcall+0x17c/0x2f0<br /> do_init_module+0xe8/0x378<br /> load_module+0x3f80/0x4a40<br /> __se_sys_finit_module+0x1a0/0x1e4<br /> __arm64_sys_finit_module+0x44/0x58<br /> el0_svc_common+0x100/0x264<br /> do_el0_svc+0x38/0xa4<br /> el0_svc+0x20/0x30<br /> el0_sync_handler+0x68/0xac<br /> el0_sync+0x160/0x180<br /> <br /> Fix this by setting dev-&gt;iommu to NULL first and<br /> then freeing dev_iommu structure in dev_iommu_free<br /> function.