Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> audit: don&amp;#39;t deref the syscall args when checking the openat2 open_how::flags<br /> <br /> As reported by Jeff, dereferencing the openat2 syscall argument in<br /> audit_match_perm() to obtain the open_how::flags can result in an<br /> oops/page-fault. This patch fixes this by using the open_how struct<br /> that we store in the audit_context with audit_openat2_how().<br /> <br /> Independent of this patch, Richard Guy Briggs posted a similar patch<br /> to the audit mailing list roughly 40 minutes after this patch was<br /> posted.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix KASAN error in LAG NETDEV_UNREGISTER handler<br /> <br /> Currently, the same handler is called for both a NETDEV_BONDING_INFO<br /> LAG unlink notification as for a NETDEV_UNREGISTER call. This is<br /> causing a problem though, since the netdev_notifier_info passed has<br /> a different structure depending on which event is passed. The problem<br /> manifests as a call trace from a BUG: KASAN stack-out-of-bounds error.<br /> <br /> Fix this by creating a handler specific to NETDEV_UNREGISTER that only<br /> is passed valid elements in the netdev_notifier_info struct for the<br /> NETDEV_UNREGISTER event.<br /> <br /> Also included is the removal of an unbalanced dev_put on the peer_netdev<br /> and related braces.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: fix panic when DSA master device unbinds on shutdown<br /> <br /> Rafael reports that on a system with LX2160A and Marvell DSA switches,<br /> if a reboot occurs while the DSA master (dpaa2-eth) is up, the following<br /> panic can be seen:<br /> <br /> systemd-shutdown[1]: Rebooting.<br /> Unable to handle kernel paging request at virtual address 00a0000800000041<br /> [00a0000800000041] address between user and kernel address ranges<br /> Internal error: Oops: 96000004 [#1] PREEMPT SMP<br /> CPU: 6 PID: 1 Comm: systemd-shutdow Not tainted 5.16.5-00042-g8f5585009b24 #32<br /> pc : dsa_slave_netdevice_event+0x130/0x3e4<br /> lr : raw_notifier_call_chain+0x50/0x6c<br /> Call trace:<br /> dsa_slave_netdevice_event+0x130/0x3e4<br /> raw_notifier_call_chain+0x50/0x6c<br /> call_netdevice_notifiers_info+0x54/0xa0<br /> __dev_close_many+0x50/0x130<br /> dev_close_many+0x84/0x120<br /> unregister_netdevice_many+0x130/0x710<br /> unregister_netdevice_queue+0x8c/0xd0<br /> unregister_netdev+0x20/0x30<br /> dpaa2_eth_remove+0x68/0x190<br /> fsl_mc_driver_remove+0x20/0x5c<br /> __device_release_driver+0x21c/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 /> __do_sys_reboot+0x1cc/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 /> It can be seen from the stack trace that the problem is that the<br /> deregistration of the master causes a dev_close(), which gets notified<br /> as NETDEV_GOING_DOWN to dsa_slave_netdevice_event().<br /> But dsa_switch_shutdown() has already run, and this has unregistered the<br /> DSA slave interfaces, and yet, the NETDEV_GOING_DOWN handler attempts to<br /> call dev_close_many() on those slave interfaces, leading to the problem.<br /> <br /> The previous attempt to avoid the NETDEV_GOING_DOWN on the master after<br /> dsa_switch_shutdown() was called seems improper. Unregistering the slave<br /> interfaces is unnecessary and unhelpful. Instead, after the slaves have<br /> stopped being uppers of the DSA master, we can now reset to NULL the<br /> master-&gt;dsa_ptr pointer, which will make DSA start ignoring all future<br /> notifier events on the master.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix a memleak when uncloning an skb dst and its metadata<br /> <br /> When uncloning an skb dst and its associated metadata, a new<br /> dst+metadata is allocated and later replaces the old one in the skb.<br /> This is helpful to have a non-shared dst+metadata attached to a specific<br /> skb.<br /> <br /> The issue is the uncloned dst+metadata is initialized with a refcount of<br /> 1, which is increased to 2 before attaching it to the skb. When<br /> tun_dst_unclone returns, the dst+metadata is only referenced from a<br /> single place (the skb) while its refcount is 2. Its refcount will never<br /> drop to 0 (when the skb is consumed), leading to a memory leak.<br /> <br /> Fix this by removing the call to dst_hold in tun_dst_unclone, as the<br /> dst+metadata refcount is already 1.

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.