Vulnerabilities

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 /> backlight: pm8941: Add NULL check in wled_configure()<br /> <br /> devm_kasprintf() returns NULL when memory allocation fails. Currently,<br /> wled_configure() does not check for this case, which results in a NULL<br /> pointer dereference.<br /> <br /> Add NULL check after devm_kasprintf() to prevent this issue.

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 /> soc: aspeed: Add NULL check in aspeed_lpc_enable_snoop()<br /> <br /> devm_kasprintf() returns NULL when memory allocation fails. Currently,<br /> aspeed_lpc_enable_snoop() does not check for this case, which results in a<br /> NULL pointer dereference.<br /> <br /> Add NULL check after devm_kasprintf() to prevent this issue.<br /> <br /> [arj: Fix Fixes: tag to use subject from 3772e5da4454]

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 />

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: 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 /> 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 /> usb: renesas_usbhs: Reorder clock handling and power management in probe<br /> <br /> Reorder the initialization sequence in `usbhs_probe()` to enable runtime<br /> PM before accessing registers, preventing potential crashes due to<br /> uninitialized clocks.<br /> <br /> Currently, in the probe path, registers are accessed before enabling the<br /> clocks, leading to a synchronous external abort on the RZ/V2H SoC.<br /> The problematic call flow is as follows:<br /> <br /> usbhs_probe()<br /> usbhs_sys_clock_ctrl()<br /> usbhs_bset()<br /> usbhs_write()<br /> iowrite16()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/pwrctrl: Cancel outstanding rescan work when unregistering<br /> <br /> It&amp;#39;s possible to trigger use-after-free here by:<br /> <br /> (a) forcing rescan_work_func() to take a long time and<br /> (b) utilizing a pwrctrl driver that may be unloaded for some reason<br /> <br /> Cancel outstanding work to ensure it is finished before we allow our data<br /> structures to be cleaned up.<br /> <br /> [bhelgaas: tidy commit log]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: ti: Add NULL check in udma_probe()<br /> <br /> devm_kasprintf() returns NULL when memory allocation fails. Currently,<br /> udma_probe() does not check for this case, which results in a NULL<br /> pointer dereference.<br /> <br /> Add NULL check after devm_kasprintf() to prevent this issue.