Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ibmvnic: don&amp;#39;t release napi in __ibmvnic_open()<br /> <br /> If __ibmvnic_open() encounters an error such as when setting link state,<br /> it calls release_resources() which frees the napi structures needlessly.<br /> Instead, have __ibmvnic_open() only clean up the work it did so far (i.e.<br /> disable napi and irqs) and leave the rest to the callers.<br /> <br /> If caller of __ibmvnic_open() is ibmvnic_open(), it should release the<br /> resources immediately. If the caller is do_reset() or do_hard_reset(),<br /> they will release the resources on the next reset.<br /> <br /> This fixes following crash that occurred when running the drmgr command<br /> several times to add/remove a vnic interface:<br /> <br /> [102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq<br /> [102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq<br /> [102056] ibmvnic 30000003 env3: Replenished 8 pools<br /> Kernel attempted to read user page (10) - exploit attempt? (uid: 0)<br /> BUG: Kernel NULL pointer dereference on read at 0x00000010<br /> Faulting instruction address: 0xc000000000a3c840<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries<br /> ...<br /> CPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted 5.16.0-rc5-autotest-g6441998e2e37 #1<br /> Workqueue: events_long __ibmvnic_reset [ibmvnic]<br /> NIP: c000000000a3c840 LR: c0080000029b5378 CTR: c000000000a3c820<br /> REGS: c0000000548e37e0 TRAP: 0300 Not tainted (5.16.0-rc5-autotest-g6441998e2e37)<br /> MSR: 8000000000009033 CR: 28248484 XER: 00000004<br /> CFAR: c0080000029bdd24 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0<br /> GPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000<br /> ...<br /> NIP [c000000000a3c840] napi_enable+0x20/0xc0<br /> LR [c0080000029b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic]<br /> Call Trace:<br /> [c0000000548e3a80] [0000000000000006] 0x6 (unreliable)<br /> [c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic]<br /> [c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic]<br /> [c0000000548e3c60] [c000000000176228] process_one_work+0x288/0x570<br /> [c0000000548e3d00] [c000000000176588] worker_thread+0x78/0x660<br /> [c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0<br /> [c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64<br /> Instruction dump:<br /> 7d2948f8 792307e0 4e800020 60000000 3c4c01eb 384239e0 f821ffd1 39430010<br /> 38a0fff6 e92d1100 f9210028 39200000 f9010020 60420000 e9210020<br /> ---[ end trace 5f8033b08fd27706 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: lantiq_gswip: 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 GSWIP 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 gswip 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 /> 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.