Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix oops in write-retry from mis-resetting the subreq iterator<br /> <br /> Fix the resetting of the subrequest iterator in netfs_retry_write_stream()<br /> to use the iterator-reset function as the iterator may have been shortened<br /> by a previous retry. In such a case, the amount of data to be written by<br /> the subrequest is not "subreq-&gt;len" but "subreq-&gt;len -<br /> subreq-&gt;transferred".<br /> <br /> Without this, KASAN may see an error in iov_iter_revert():<br /> <br /> BUG: KASAN: slab-out-of-bounds in iov_iter_revert lib/iov_iter.c:633 [inline]<br /> BUG: KASAN: slab-out-of-bounds in iov_iter_revert+0x443/0x5a0 lib/iov_iter.c:611<br /> Read of size 4 at addr ffff88802912a0b8 by task kworker/u32:7/1147<br /> <br /> CPU: 1 UID: 0 PID: 1147 Comm: kworker/u32:7 Not tainted 6.15.0-rc6-syzkaller-00052-g9f35e33144ae #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> Workqueue: events_unbound netfs_write_collection_worker<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:408 [inline]<br /> print_report+0xc3/0x670 mm/kasan/report.c:521<br /> kasan_report+0xe0/0x110 mm/kasan/report.c:634<br /> iov_iter_revert lib/iov_iter.c:633 [inline]<br /> iov_iter_revert+0x443/0x5a0 lib/iov_iter.c:611<br /> netfs_retry_write_stream fs/netfs/write_retry.c:44 [inline]<br /> netfs_retry_writes+0x166d/0x1a50 fs/netfs/write_retry.c:231<br /> netfs_collect_write_results fs/netfs/write_collect.c:352 [inline]<br /> netfs_write_collection_worker+0x23fd/0x3830 fs/netfs/write_collect.c:374<br /> process_one_work+0x9cf/0x1b70 kernel/workqueue.c:3238<br /> process_scheduled_works kernel/workqueue.c:3319 [inline]<br /> worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400<br /> kthread+0x3c2/0x780 kernel/kthread.c:464<br /> ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm: limit swapping tables for devices with zone write plugs<br /> <br /> dm_revalidate_zones() only allowed new or previously unzoned devices to<br /> call blk_revalidate_disk_zones(). If the device was already zoned,<br /> disk-&gt;nr_zones would always equal md-&gt;nr_zones, so dm_revalidate_zones()<br /> returned without doing any work. This would make the zoned settings for<br /> the device not match the new table. If the device had zone write plug<br /> resources, it could run into errors like bdev_zone_is_seq() reading<br /> invalid memory because disk-&gt;conv_zones_bitmap was the wrong size.<br /> <br /> If the device doesn&amp;#39;t have any zone write plug resources, calling<br /> blk_revalidate_disk_zones() will always correctly update device. If<br /> blk_revalidate_disk_zones() fails, it can still overwrite or clear the<br /> current disk-&gt;nr_zones value. In this case, DM must restore the previous<br /> value of disk-&gt;nr_zones, so that the zoned settings will continue to<br /> match the previous value that it fell back to.<br /> <br /> If the device already has zone write plug resources,<br /> blk_revalidate_disk_zones() will not correctly update them, if it is<br /> called for arbitrary zoned device changes. Since there is not much need<br /> for this ability, the easiest solution is to disallow any table reloads<br /> that change the zoned settings, for devices that already have zone plug<br /> resources. Specifically, if a device already has zone plug resources<br /> allocated, it can only switch to another zoned table that also emulates<br /> zone append. Also, it cannot change the device size or the zone size. A<br /> device can switch to an error target.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm: fix dm_blk_report_zones<br /> <br /> If dm_get_live_table() returned NULL, dm_put_live_table() was never<br /> called. Also, it is possible that md-&gt;zone_revalidate_map will change<br /> while calling this function. Only read it once, so that we are always<br /> using the same value. Otherwise we might miss a call to<br /> dm_put_live_table().<br /> <br /> Finally, while md-&gt;zone_revalidate_map is set and a process is calling<br /> blk_revalidate_disk_zones() to set up the zone append emulation<br /> resources, it is possible that another process, perhaps triggered by<br /> blkdev_report_zones_ioctl(), will call dm_blk_report_zones(). If<br /> blk_revalidate_disk_zones() fails, these resources can be freed while<br /> the other process is still using them, causing a use-after-free error.<br /> <br /> blk_revalidate_disk_zones() will only ever be called when initially<br /> setting up the zone append emulation resources, such as when setting up<br /> a zoned dm-crypt table for the first time. Further table swaps will not<br /> set md-&gt;zone_revalidate_map or call blk_revalidate_disk_zones().<br /> However it must be called using the new table (referenced by<br /> md-&gt;zone_revalidate_map) and the new queue limits while the DM device is<br /> suspended. dm_blk_report_zones() needs some way to distinguish between a<br /> call from blk_revalidate_disk_zones(), which must be allowed to use<br /> md-&gt;zone_revalidate_map to access this not yet activated table, and all<br /> other calls to dm_blk_report_zones(), which should not be allowed while<br /> the device is suspended and cannot use md-&gt;zone_revalidate_map, since<br /> the zone resources might be freed by the process currently calling<br /> blk_revalidate_disk_zones().<br /> <br /> Solve this by tracking the process that sets md-&gt;zone_revalidate_map in<br /> dm_revalidate_zones() and only allowing that process to make use of it<br /> in dm_blk_report_zones().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (asus-ec-sensors) check sensor index in read_string()<br /> <br /> Prevent a potential invalid memory access when the requested sensor<br /> is not found.<br /> <br /> find_ec_sensor_index() may return a negative value (e.g. -ENOENT),<br /> but its result was used without checking, which could lead to<br /> undefined behavior when passed to get_sensor_info().<br /> <br /> Add a proper check to return -EINVAL if sensor_index is negative.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.<br /> <br /> [groeck: Return error code returned from find_ec_sensor_index]