Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7996: Fix null-ptr-deref in mt7996_mmio_wed_init()<br /> <br /> devm_ioremap() returns NULL on error. Currently, mt7996_mmio_wed_init()<br /> does not check for this case, which results in a NULL pointer<br /> dereference.<br /> <br /> Prevent null pointer dereference in mt7996_mmio_wed_init()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hisi_acc_vfio_pci: fix XQE dma address error<br /> <br /> The dma addresses of EQE and AEQE are wrong after migration and<br /> results in guest kernel-mode encryption services failure.<br /> Comparing the definition of hardware registers, we found that<br /> there was an error when the data read from the register was<br /> combined into an address. Therefore, the address combination<br /> sequence needs to be corrected.<br /> <br /> Even after fixing the above problem, we still have an issue<br /> where the Guest from an old kernel can get migrated to<br /> new kernel and may result in wrong data.<br /> <br /> In order to ensure that the address is correct after migration,<br /> if an old magic number is detected, the dma address needs to be<br /> updated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/cma: Fix hang when cma_netevent_callback fails to queue_work<br /> <br /> The cited commit fixed a crash when cma_netevent_callback was called for<br /> a cma_id while work on that id from a previous call had not yet started.<br /> The work item was re-initialized in the second call, which corrupted the<br /> work item currently in the work queue.<br /> <br /> However, it left a problem when queue_work fails (because the item is<br /> still pending in the work queue from a previous call). In this case,<br /> cma_id_put (which is called in the work handler) is therefore not<br /> called. This results in a userspace process hang (zombie process).<br /> <br /> Fix this by calling cma_id_put() if queue_work fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: aqc111: fix error handling of usbnet read calls<br /> <br /> Syzkaller, courtesy of syzbot, identified an error (see report [1]) in<br /> aqc111 driver, caused by incomplete sanitation of usb read calls&amp;#39;<br /> results. This problem is quite similar to the one fixed in commit<br /> 920a9fa27e78 ("net: asix: add proper error handling of usb read errors").<br /> <br /> For instance, usbnet_read_cmd() may read fewer than &amp;#39;size&amp;#39; bytes,<br /> even if the caller expected the full amount, and aqc111_read_cmd()<br /> will not check its result properly. As [1] shows, this may lead<br /> to MAC address in aqc111_bind() being only partly initialized,<br /> triggering KMSAN warnings.<br /> <br /> Fix the issue by verifying that the number of bytes read is<br /> as expected and not less.<br /> <br /> [1] Partial syzbot report:<br /> BUG: KMSAN: uninit-value in is_valid_ether_addr include/linux/etherdevice.h:208 [inline]<br /> BUG: KMSAN: uninit-value in usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830<br /> is_valid_ether_addr include/linux/etherdevice.h:208 [inline]<br /> usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830<br /> usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396<br /> call_driver_probe drivers/base/dd.c:-1 [inline]<br /> really_probe+0x4d1/0xd90 drivers/base/dd.c:658<br /> __driver_probe_device+0x268/0x380 drivers/base/dd.c:800<br /> ...<br /> <br /> Uninit was stored to memory at:<br /> dev_addr_mod+0xb0/0x550 net/core/dev_addr_lists.c:582<br /> __dev_addr_set include/linux/netdevice.h:4874 [inline]<br /> eth_hw_addr_set include/linux/etherdevice.h:325 [inline]<br /> aqc111_bind+0x35f/0x1150 drivers/net/usb/aqc111.c:717<br /> usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772<br /> usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396<br /> ...<br /> <br /> Uninit was stored to memory at:<br /> ether_addr_copy include/linux/etherdevice.h:305 [inline]<br /> aqc111_read_perm_mac drivers/net/usb/aqc111.c:663 [inline]<br /> aqc111_bind+0x794/0x1150 drivers/net/usb/aqc111.c:713<br /> usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772<br /> usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396<br /> call_driver_probe drivers/base/dd.c:-1 [inline]<br /> ...<br /> <br /> Local variable buf.i created at:<br /> aqc111_read_perm_mac drivers/net/usb/aqc111.c:656 [inline]<br /> aqc111_bind+0x221/0x1150 drivers/net/usb/aqc111.c:713<br /> usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Avoid using sk_socket after free when sending<br /> <br /> The sk-&gt;sk_socket is not locked or referenced in backlog thread, and<br /> during the call to skb_send_sock(), there is a race condition with<br /> the release of sk_socket. All types of sockets(tcp/udp/unix/vsock)<br /> will be affected.<br /> <br /> Race conditions:<br /> &amp;#39;&amp;#39;&amp;#39;<br /> CPU0 CPU1<br /> <br /> backlog::skb_send_sock<br /> sendmsg_unlocked<br /> sock_sendmsg<br /> sock_sendmsg_nosec<br /> close(fd):<br /> ...<br /> ops-&gt;release() -&gt; sock_map_close()<br /> sk_socket-&gt;ops = NULL<br /> free(socket)<br /> sock-&gt;ops-&gt;sendmsg<br /> ^<br /> panic here<br /> &amp;#39;&amp;#39;&amp;#39;<br /> <br /> The ref of psock become 0 after sock_map_close() executed.<br /> &amp;#39;&amp;#39;&amp;#39;<br /> void sock_map_close()<br /> {<br /> ...<br /> if (likely(psock)) {<br /> ...<br /> // !! here we remove psock and the ref of psock become 0<br /> sock_map_remove_links(sk, psock)<br /> psock = sk_psock_get(sk);<br /> if (unlikely(!psock))<br /> goto no_psock; work);

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k_htc: Abort software beacon handling if disabled<br /> <br /> A malicious USB device can send a WMI_SWBA_EVENTID event from an<br /> ath9k_htc-managed device before beaconing has been enabled. This causes<br /> a device-by-zero error in the driver, leading to either a crash or an<br /> out of bounds read.<br /> <br /> Prevent this by aborting the handling in ath9k_htc_swba() if beacons are<br /> not enabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phy: clear phydev-&gt;devlink when the link is deleted<br /> <br /> There is a potential crash issue when disabling and re-enabling the<br /> network port. When disabling the network port, phy_detach() calls<br /> device_link_del() to remove the device link, but it does not clear<br /> phydev-&gt;devlink, so phydev-&gt;devlink is not a NULL pointer. Then the<br /> network port is re-enabled, but if phy_attach_direct() fails before<br /> calling device_link_add(), the code jumps to the "error" label and<br /> calls phy_detach(). Since phydev-&gt;devlink retains the old value from<br /> the previous attach/detach cycle, device_link_del() uses the old value,<br /> which accesses a NULL pointer and causes a crash. The simplified crash<br /> log is as follows.<br /> <br /> [ 24.702421] Call trace:<br /> [ 24.704856] device_link_put_kref+0x20/0x120<br /> [ 24.709124] device_link_del+0x30/0x48<br /> [ 24.712864] phy_detach+0x24/0x168<br /> [ 24.716261] phy_attach_direct+0x168/0x3a4<br /> [ 24.720352] phylink_fwnode_phy_connect+0xc8/0x14c<br /> [ 24.725140] phylink_of_phy_connect+0x1c/0x34<br /> <br /> Therefore, phydev-&gt;devlink needs to be cleared when the device link is<br /> deleted.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> watchdog: lenovo_se30_wdt: Fix possible devm_ioremap() NULL pointer dereference in lenovo_se30_wdt_probe()<br /> <br /> devm_ioremap() returns NULL on error. Currently, lenovo_se30_wdt_probe()<br /> does not check for this case, which results in a NULL pointer<br /> dereference.<br /> <br /> Add NULL check after devm_ioremap() to prevent this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_packet: move notifier&amp;#39;s packet_dev_mc out of rcu critical section<br /> <br /> Syzkaller reports the following issue:<br /> <br /> BUG: sleeping function called from invalid context at kernel/locking/mutex.c:578<br /> __mutex_lock+0x106/0xe80 kernel/locking/mutex.c:746<br /> team_change_rx_flags+0x38/0x220 drivers/net/team/team_core.c:1781<br /> dev_change_rx_flags net/core/dev.c:9145 [inline]<br /> __dev_set_promiscuity+0x3f8/0x590 net/core/dev.c:9189<br /> netif_set_promiscuity+0x50/0xe0 net/core/dev.c:9201<br /> dev_set_promiscuity+0x126/0x260 net/core/dev_api.c:286 packet_dev_mc net/packet/af_packet.c:3698 [inline]<br /> packet_dev_mclist_delete net/packet/af_packet.c:3722 [inline]<br /> packet_notifier+0x292/0xa60 net/packet/af_packet.c:4247<br /> notifier_call_chain+0x1b3/0x3e0 kernel/notifier.c:85<br /> call_netdevice_notifiers_extack net/core/dev.c:2214 [inline]<br /> call_netdevice_notifiers net/core/dev.c:2228 [inline]<br /> unregister_netdevice_many_notify+0x15d8/0x2330 net/core/dev.c:11972<br /> rtnl_delete_link net/core/rtnetlink.c:3522 [inline]<br /> rtnl_dellink+0x488/0x710 net/core/rtnetlink.c:3564<br /> rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6955<br /> netlink_rcv_skb+0x219/0x490 net/netlink/af_netlink.c:2534<br /> <br /> Calling `PACKET_ADD_MEMBERSHIP` on an ops-locked device can trigger<br /> the `NETDEV_UNREGISTER` notifier, which may require disabling promiscuous<br /> and/or allmulti mode. Both of these operations require acquiring<br /> the netdev instance lock.<br /> <br /> Move the call to `packet_dev_mc` outside of the RCU critical section.<br /> The `mclist` modifications (add, del, flush, unregister) are protected by<br /> the RTNL, not the RCU. The RCU only protects the `sklist` and its<br /> associated `sks`. The delayed operation on the `mclist` entry remains<br /> within the RTNL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> calipso: Don&amp;#39;t call calipso functions for AF_INET sk.<br /> <br /> syzkaller reported a null-ptr-deref in txopt_get(). [0]<br /> <br /> The offset 0x70 was of struct ipv6_txoptions in struct ipv6_pinfo,<br /> so struct ipv6_pinfo was NULL there.<br /> <br /> However, this never happens for IPv6 sockets as inet_sk(sk)-&gt;pinet6<br /> is always set in inet6_create(), meaning the socket was not IPv6 one.<br /> <br /> The root cause is missing validation in netlbl_conn_setattr().<br /> <br /> netlbl_conn_setattr() switches branches based on struct<br /> sockaddr.sa_family, which is passed from userspace. However,<br /> netlbl_conn_setattr() does not check if the address family matches<br /> the socket.<br /> <br /> The syzkaller must have called connect() for an IPv6 address on<br /> an IPv4 socket.<br /> <br /> We have a proper validation in tcp_v[46]_connect(), but<br /> security_socket_connect() is called in the earlier stage.<br /> <br /> Let&amp;#39;s copy the validation to netlbl_conn_setattr().<br /> <br /> [0]:<br /> Oops: general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]<br /> CPU: 2 UID: 0 PID: 12928 Comm: syz.9.1677 Not tainted 6.12.0 #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> RIP: 0010:txopt_get include/net/ipv6.h:390 [inline]<br /> RIP: 0010:<br /> Code: 02 00 00 49 8b ac 24 f8 02 00 00 e8 84 69 2a fd e8 ff 00 16 fd 48 8d 7d 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 3c 02 00 0f 85 53 02 00 00 48 8b 6d 70 48 85 ed 0f 84 ab 01 00<br /> RSP: 0018:ffff88811b8afc48 EFLAGS: 00010212<br /> RAX: dffffc0000000000 RBX: 1ffff11023715f8a RCX: ffffffff841ab00c<br /> RDX: 000000000000000e RSI: ffffc90007d9e000 RDI: 0000000000000070<br /> RBP: 0000000000000000 R08: ffffed1023715f9d R09: ffffed1023715f9e<br /> R10: ffffed1023715f9d R11: 0000000000000003 R12: ffff888123075f00<br /> R13: ffff88810245bd80 R14: ffff888113646780 R15: ffff888100578a80<br /> FS: 00007f9019bd7640(0000) GS:ffff8882d2d00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f901b927bac CR3: 0000000104788003 CR4: 0000000000770ef0<br /> PKRU: 80000000<br /> Call Trace:<br /> <br /> calipso_sock_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:557<br /> netlbl_conn_setattr+0x10c/0x280 net/netlabel/netlabel_kapi.c:1177<br /> selinux_netlbl_socket_connect_helper+0xd3/0x1b0 security/selinux/netlabel.c:569<br /> selinux_netlbl_socket_connect_locked security/selinux/netlabel.c:597 [inline]<br /> selinux_netlbl_socket_connect+0xb6/0x100 security/selinux/netlabel.c:615<br /> selinux_socket_connect+0x5f/0x80 security/selinux/hooks.c:4931<br /> security_socket_connect+0x50/0xa0 security/security.c:4598<br /> __sys_connect_file+0xa4/0x190 net/socket.c:2067<br /> __sys_connect+0x12c/0x170 net/socket.c:2088<br /> __do_sys_connect net/socket.c:2098 [inline]<br /> __se_sys_connect net/socket.c:2095 [inline]<br /> __x64_sys_connect+0x73/0xb0 net/socket.c:2095<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f901b61a12d<br /> Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f9019bd6fa8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a<br /> RAX: ffffffffffffffda RBX: 00007f901b925fa0 RCX: 00007f901b61a12d<br /> RDX: 000000000000001c RSI: 0000200000000140 RDI: 0000000000000003<br /> RBP: 00007f901b701505 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 00007f901b5b62a0 R15: 00007f9019bb7000<br /> <br /> Modules linked in:

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phy: mscc: Fix memory leak when using one step timestamping<br /> <br /> Fix memory leak when running one-step timestamping. When running<br /> one-step sync timestamping, the HW is configured to insert the TX time<br /> into the frame, so there is no reason to keep the skb anymore. As in<br /> this case the HW will never generate an interrupt to say that the frame<br /> was timestamped, then the frame will never released.<br /> Fix this by freeing the frame in case of one-step timestamping.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: openvswitch: Fix the dead loop of MPLS parse<br /> <br /> The unexpected MPLS packet may not end with the bottom label stack.<br /> When there are many stacks, The label count value has wrapped around.<br /> A dead loop occurs, soft lockup/CPU stuck finally.<br /> <br /> stack backtrace:<br /> UBSAN: array-index-out-of-bounds in /build/linux-0Pa0xK/linux-5.15.0/net/openvswitch/flow.c:662:26<br /> index -1 is out of range for type &amp;#39;__be32 [3]&amp;#39;<br /> CPU: 34 PID: 0 Comm: swapper/34 Kdump: loaded Tainted: G OE 5.15.0-121-generic #131-Ubuntu<br /> Hardware name: Dell Inc. PowerEdge C6420/0JP9TF, BIOS 2.12.2 07/14/2021<br /> Call Trace:<br /> <br /> show_stack+0x52/0x5c<br /> dump_stack_lvl+0x4a/0x63<br /> dump_stack+0x10/0x16<br /> ubsan_epilogue+0x9/0x36<br /> __ubsan_handle_out_of_bounds.cold+0x44/0x49<br /> key_extract_l3l4+0x82a/0x840 [openvswitch]<br /> ? kfree_skbmem+0x52/0xa0<br /> key_extract+0x9c/0x2b0 [openvswitch]<br /> ovs_flow_key_extract+0x124/0x350 [openvswitch]<br /> ovs_vport_receive+0x61/0xd0 [openvswitch]<br /> ? kernel_init_free_pages.part.0+0x4a/0x70<br /> ? get_page_from_freelist+0x353/0x540<br /> netdev_port_receive+0xc4/0x180 [openvswitch]<br /> ? netdev_port_receive+0x180/0x180 [openvswitch]<br /> netdev_frame_hook+0x1f/0x40 [openvswitch]<br /> __netif_receive_skb_core.constprop.0+0x23a/0xf00<br /> __netif_receive_skb_list_core+0xfa/0x240<br /> netif_receive_skb_list_internal+0x18e/0x2a0<br /> napi_complete_done+0x7a/0x1c0<br /> bnxt_poll+0x155/0x1c0 [bnxt_en]<br /> __napi_poll+0x30/0x180<br /> net_rx_action+0x126/0x280<br /> ? bnxt_msix+0x67/0x80 [bnxt_en]<br /> handle_softirqs+0xda/0x2d0<br /> irq_exit_rcu+0x96/0xc0<br /> common_interrupt+0x8e/0xa0<br />