Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipmr,ip6mr: acquire RTNL before calling ip[6]mr_free_table() on failure path<br /> <br /> ip[6]mr_free_table() can only be called under RTNL lock.<br /> <br /> RTNL: assertion failed at net/core/dev.c (10367)<br /> WARNING: CPU: 1 PID: 5890 at net/core/dev.c:10367 unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367<br /> Modules linked in:<br /> CPU: 1 PID: 5890 Comm: syz-executor.2 Not tainted 5.16.0-syzkaller-11627-g422ee58dc0ef #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367<br /> Code: 0f 85 9b ee ff ff e8 69 07 4b fa ba 7f 28 00 00 48 c7 c6 00 90 ae 8a 48 c7 c7 40 90 ae 8a c6 05 6d b1 51 06 01 e8 8c 90 d8 01 0b e9 70 ee ff ff e8 3e 07 4b fa 4c 89 e7 e8 86 2a 59 fa e9 ee<br /> RSP: 0018:ffffc900046ff6e0 EFLAGS: 00010286<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000<br /> RDX: ffff888050f51d00 RSI: ffffffff815fa008 RDI: fffff520008dfece<br /> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000<br /> R10: ffffffff815f3d6e R11: 0000000000000000 R12: 00000000fffffff4<br /> R13: dffffc0000000000 R14: ffffc900046ff750 R15: ffff88807b7dc000<br /> FS: 00007f4ab736e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fee0b4f8990 CR3: 000000001e7d2000 CR4: 00000000003506e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> mroute_clean_tables+0x244/0xb40 net/ipv6/ip6mr.c:1509<br /> ip6mr_free_table net/ipv6/ip6mr.c:389 [inline]<br /> ip6mr_rules_init net/ipv6/ip6mr.c:246 [inline]<br /> ip6mr_net_init net/ipv6/ip6mr.c:1306 [inline]<br /> ip6mr_net_init+0x3f0/0x4e0 net/ipv6/ip6mr.c:1298<br /> ops_init+0xaf/0x470 net/core/net_namespace.c:140<br /> setup_net+0x54f/0xbb0 net/core/net_namespace.c:331<br /> copy_net_ns+0x318/0x760 net/core/net_namespace.c:475<br /> create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110<br /> copy_namespaces+0x391/0x450 kernel/nsproxy.c:178<br /> copy_process+0x2e0c/0x7300 kernel/fork.c:2167<br /> kernel_clone+0xe7/0xab0 kernel/fork.c:2555<br /> __do_sys_clone+0xc8/0x110 kernel/fork.c:2672<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f4ab89f9059<br /> Code: Unable to access opcode bytes at RIP 0x7f4ab89f902f.<br /> RSP: 002b:00007f4ab736e118 EFLAGS: 00000206 ORIG_RAX: 0000000000000038<br /> RAX: ffffffffffffffda RBX: 00007f4ab8b0bf60 RCX: 00007f4ab89f9059<br /> RDX: 0000000020000280 RSI: 0000000020000270 RDI: 0000000040200000<br /> RBP: 00007f4ab8a5308d R08: 0000000020000300 R09: 0000000020000300<br /> R10: 00000000200002c0 R11: 0000000000000206 R12: 0000000000000000<br /> R13: 00007ffc3977cc1f R14: 00007f4ab736e300 R15: 0000000000022000<br />

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.