Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: ipc4-mtrace: prevent underflow in sof_ipc4_priority_mask_dfs_write()<br /> <br /> The "id" comes from the user. Change the type to unsigned to prevent<br /> an array underflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix NULL pointer in skb_segment_list<br /> <br /> Commit 3a1296a38d0c ("net: Support GRO/GSO fraglist chaining.")<br /> introduced UDP listifyed GRO. The segmentation relies on frag_list being<br /> untouched when passing through the network stack. This assumption can be<br /> broken sometimes, where frag_list itself gets pulled into linear area,<br /> leaving frag_list being NULL. When this happens it can trigger<br /> following NULL pointer dereference, and panic the kernel. Reverse the<br /> test condition should fix it.<br /> <br /> [19185.577801][ C1] BUG: kernel NULL pointer dereference, address:<br /> ...<br /> [19185.663775][ C1] RIP: 0010:skb_segment_list+0x1cc/0x390<br /> ...<br /> [19185.834644][ C1] Call Trace:<br /> [19185.841730][ C1] <br /> [19185.848563][ C1] __udp_gso_segment+0x33e/0x510<br /> [19185.857370][ C1] inet_gso_segment+0x15b/0x3e0<br /> [19185.866059][ C1] skb_mac_gso_segment+0x97/0x110<br /> [19185.874939][ C1] __skb_gso_segment+0xb2/0x160<br /> [19185.883646][ C1] udp_queue_rcv_skb+0xc3/0x1d0<br /> [19185.892319][ C1] udp_unicast_rcv_skb+0x75/0x90<br /> [19185.900979][ C1] ip_protocol_deliver_rcu+0xd2/0x200<br /> [19185.910003][ C1] ip_local_deliver_finish+0x44/0x60<br /> [19185.918757][ C1] __netif_receive_skb_one_core+0x8b/0xa0<br /> [19185.927834][ C1] process_backlog+0x88/0x130<br /> [19185.935840][ C1] __napi_poll+0x27/0x150<br /> [19185.943447][ C1] net_rx_action+0x27e/0x5f0<br /> [19185.951331][ C1] ? mlx5_cq_tasklet_cb+0x70/0x160 [mlx5_core]<br /> [19185.960848][ C1] __do_softirq+0xbc/0x25d<br /> [19185.968607][ C1] irq_exit_rcu+0x83/0xb0<br /> [19185.976247][ C1] common_interrupt+0x43/0xa0<br /> [19185.984235][ C1] asm_common_interrupt+0x22/0x40<br /> ...<br /> [19186.094106][ C1]

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: ublk: extending queue_size to fix overflow<br /> <br /> When validating drafted SPDK ublk target, in a case that<br /> assigning large queue depth to multiqueue ublk device,<br /> ublk target would run into a weird incorrect state. During<br /> rounds of review and debug, An overflow bug was found<br /> in ublk driver.<br /> <br /> In ublk_cmd.h, UBLK_MAX_QUEUE_DEPTH is 4096 which means<br /> each ublk queue depth can be set as large as 4096. But<br /> when setting qd for a ublk device,<br /> sizeof(struct ublk_queue) + depth * sizeof(struct ublk_io)<br /> will be larger than 65535 if qd is larger than 2728.<br /> Then queue_size is overflowed, and ublk_get_queue()<br /> references a wrong pointer position. The wrong content of<br /> ublk_queue elements will lead to out-of-bounds memory<br /> access.<br /> <br /> Extend queue_size in ublk_device as "unsigned int".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fscache: Use wait_on_bit() to wait for the freeing of relinquished volume<br /> <br /> The freeing of relinquished volume will wake up the pending volume<br /> acquisition by using wake_up_bit(), however it is mismatched with<br /> wait_var_event() used in fscache_wait_on_volume_collision() and it will<br /> never wake up the waiter in the wait-queue because these two functions<br /> operate on different wait-queues.<br /> <br /> According to the implementation in fscache_wait_on_volume_collision(),<br /> if the wake-up of pending acquisition is delayed longer than 20 seconds<br /> (e.g., due to the delay of on-demand fd closing), the first<br /> wait_var_event_timeout() will timeout and the following wait_var_event()<br /> will hang forever as shown below:<br /> <br /> FS-Cache: Potential volume collision new=00000024 old=00000022<br /> ......<br /> INFO: task mount:1148 blocked for more than 122 seconds.<br /> Not tainted 6.1.0-rc6+ #1<br /> task:mount state:D stack:0 pid:1148 ppid:1<br /> Call Trace:<br /> <br /> __schedule+0x2f6/0xb80<br /> schedule+0x67/0xe0<br /> fscache_wait_on_volume_collision.cold+0x80/0x82<br /> __fscache_acquire_volume+0x40d/0x4e0<br /> erofs_fscache_register_volume+0x51/0xe0 [erofs]<br /> erofs_fscache_register_fs+0x19c/0x240 [erofs]<br /> erofs_fc_fill_super+0x746/0xaf0 [erofs]<br /> vfs_get_super+0x7d/0x100<br /> get_tree_nodev+0x16/0x20<br /> erofs_fc_get_tree+0x20/0x30 [erofs]<br /> vfs_get_tree+0x24/0xb0<br /> path_mount+0x2fa/0xa90<br /> do_mount+0x7c/0xa0<br /> __x64_sys_mount+0x8b/0xe0<br /> do_syscall_64+0x30/0x60<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> Considering that wake_up_bit() is more selective, so fix it by using<br /> wait_on_bit() instead of wait_var_event() to wait for the freeing of<br /> relinquished volume. In addition because waitqueue_active() is used in<br /> wake_up_bit() and clear_bit() doesn&amp;#39;t imply any memory barrier, use<br /> clear_and_wake_up_bit() to add the missing memory barrier between<br /> cursor-&gt;flags and waitqueue_active().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phy: dp83822: Fix null pointer access on DP83825/DP83826 devices<br /> <br /> The probe() function is only used for the DP83822 PHY, leaving the<br /> private data pointer uninitialized for the smaller DP83825/26 models.<br /> While all uses of the private data structure are hidden in 82822 specific<br /> callbacks, configuring the interrupt is shared across all models.<br /> This causes a NULL pointer dereference on the smaller PHYs as it accesses<br /> the private data unchecked. Verifying the pointer avoids that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: dts: imx8mm-verdin: Do not power down eth-phy<br /> <br /> Currently if suspending using either freeze or memory state, the fec<br /> driver tries to power down the phy which leads to crash of the kernel<br /> and non-responsible kernel with the following call trace:<br /> <br /> [ 24.839889 ] Call trace:<br /> [ 24.839892 ] phy_error+0x18/0x60<br /> [ 24.839898 ] kszphy_handle_interrupt+0x6c/0x80<br /> [ 24.839903 ] phy_interrupt+0x20/0x2c<br /> [ 24.839909 ] irq_thread_fn+0x30/0xa0<br /> [ 24.839919 ] irq_thread+0x178/0x2c0<br /> [ 24.839925 ] kthread+0x154/0x160<br /> [ 24.839932 ] ret_from_fork+0x10/0x20<br /> <br /> Since there is currently no functionality in the phy subsystem to power<br /> down phys let&amp;#39;s just disable the feature of powering-down the ethernet<br /> phy.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Check for any of tcp_bpf_prots when cloning a listener<br /> <br /> A listening socket linked to a sockmap has its sk_prot overridden. It<br /> points to one of the struct proto variants in tcp_bpf_prots. The variant<br /> depends on the socket&amp;#39;s family and which sockmap programs are attached.<br /> <br /> A child socket cloned from a TCP listener initially inherits their sk_prot.<br /> But before cloning is finished, we restore the child&amp;#39;s proto to the<br /> listener&amp;#39;s original non-tcp_bpf_prots one. This happens in<br /> tcp_create_openreq_child -&gt; tcp_bpf_clone.<br /> <br /> Today, in tcp_bpf_clone we detect if the child&amp;#39;s proto should be restored<br /> by checking only for the TCP_BPF_BASE proto variant. This is not<br /> correct. The sk_prot of listening socket linked to a sockmap can point to<br /> to any variant in tcp_bpf_prots.<br /> <br /> If the listeners sk_prot happens to be not the TCP_BPF_BASE variant, then<br /> the child socket unintentionally is left if the inherited sk_prot by<br /> tcp_bpf_clone.<br /> <br /> This leads to issues like infinite recursion on close [1], because the<br /> child state is otherwise not set up for use with tcp_bpf_prot operations.<br /> <br /> Adjust the check in tcp_bpf_clone to detect all of tcp_bpf_prots variants.<br /> <br /> Note that it wouldn&amp;#39;t be sufficient to check the socket state when<br /> overriding the sk_prot in tcp_bpf_update_proto in order to always use the<br /> TCP_BPF_BASE variant for listening sockets. Since commit<br /> b8b8315e39ff ("bpf, sockmap: Remove unhash handler for BPF sockmap usage")<br /> it is possible for a socket to transition to TCP_LISTEN state while already<br /> linked to a sockmap, e.g. connect() -&gt; insert into map -&gt;<br /> connect(AF_UNSPEC) -&gt; listen().<br /> <br /> [1]: https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block, bfq: fix uaf for bfqq in bic_set_bfqq()<br /> <br /> After commit 64dc8c732f5c ("block, bfq: fix possible uaf for &amp;#39;bfqq-&gt;bic&amp;#39;"),<br /> bic-&gt;bfqq will be accessed in bic_set_bfqq(), however, in some context<br /> bic-&gt;bfqq will be freed, and bic_set_bfqq() is called with the freed<br /> bic-&gt;bfqq.<br /> <br /> Fix the problem by always freeing bfqq after bic_set_bfqq().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: Fix request ref counting during error capture &amp; debugfs dump<br /> <br /> When GuC support was added to error capture, the reference counting<br /> around the request object was broken. Fix it up.<br /> <br /> The context based search manages the spinlocking around the search<br /> internally. So it needs to grab the reference count internally as<br /> well. The execlist only request based search relies on external<br /> locking, so it needs an external reference count but within the<br /> spinlock not outside it.<br /> <br /> The only other caller of the context based search is the code for<br /> dumping engine state to debugfs. That code wasn&amp;#39;t previously getting<br /> an explicit reference at all as it does everything while holding the<br /> execlist specific spinlock. So, that needs updaing as well as that<br /> spinlock doesn&amp;#39;t help when using GuC submission. Rather than trying to<br /> conditionally get/put depending on submission model, just change it to<br /> always do the get/put.<br /> <br /> v2: Explicitly document adding an extra blank line in some dense code<br /> (Andy Shevchenko). Fix multiple potential null pointer derefs in case<br /> of no request found (some spotted by Tvrtko, but there was more!).<br /> Also fix a leaked request in case of !started and another in<br /> __guc_reset_context now that intel_context_find_active_request is<br /> actually reference counting the returned request.<br /> v3: Add a _get suffix to intel_context_find_active_request now that it<br /> grabs a reference (Daniele).<br /> v4: Split the intel_guc_find_hung_context change to a separate patch<br /> and rename intel_context_find_active_request_get to<br /> intel_context_get_active_request (Tvrtko).<br /> v5: s/locking/reference counting/ in commit message (Tvrtko)<br /> <br /> (cherry picked from commit 3700e353781e27f1bc7222f51f2cc36cbeb9b4ec)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF<br /> <br /> After a call to console_unlock() in vcs_read() the vc_data struct can be<br /> freed by vc_deallocate(). Because of that, the struct vc_data pointer<br /> load must be done at the top of while loop in vcs_read() to avoid a UAF<br /> when vcs_size() is called.<br /> <br /> Syzkaller reported a UAF in vcs_size().<br /> <br /> BUG: KASAN: use-after-free in vcs_size (drivers/tty/vt/vc_screen.c:215)<br /> Read of size 4 at addr ffff8881137479a8 by task 4a005ed81e27e65/1537<br /> <br /> CPU: 0 PID: 1537 Comm: 4a005ed81e27e65 Not tainted 6.2.0-rc5 #1<br /> Hardware name: Red Hat KVM, BIOS 1.15.0-2.module<br /> Call Trace:<br /> <br /> __asan_report_load4_noabort (mm/kasan/report_generic.c:350)<br /> vcs_size (drivers/tty/vt/vc_screen.c:215)<br /> vcs_read (drivers/tty/vt/vc_screen.c:415)<br /> vfs_read (fs/read_write.c:468 fs/read_write.c:450)<br /> ...<br /> <br /> <br /> Allocated by task 1191:<br /> ...<br /> kmalloc_trace (mm/slab_common.c:1069)<br /> vc_allocate (./include/linux/slab.h:580 ./include/linux/slab.h:720<br /> drivers/tty/vt/vt.c:1128 drivers/tty/vt/vt.c:1108)<br /> con_install (drivers/tty/vt/vt.c:3383)<br /> tty_init_dev (drivers/tty/tty_io.c:1301 drivers/tty/tty_io.c:1413<br /> drivers/tty/tty_io.c:1390)<br /> tty_open (drivers/tty/tty_io.c:2080 drivers/tty/tty_io.c:2126)<br /> chrdev_open (fs/char_dev.c:415)<br /> do_dentry_open (fs/open.c:883)<br /> vfs_open (fs/open.c:1014)<br /> ...<br /> <br /> Freed by task 1548:<br /> ...<br /> kfree (mm/slab_common.c:1021)<br /> vc_port_destruct (drivers/tty/vt/vt.c:1094)<br /> tty_port_destructor (drivers/tty/tty_port.c:296)<br /> tty_port_put (drivers/tty/tty_port.c:312)<br /> vt_disallocate_all (drivers/tty/vt/vt_ioctl.c:662 (discriminator 2))<br /> vt_ioctl (drivers/tty/vt/vt_ioctl.c:903)<br /> tty_ioctl (drivers/tty/tty_io.c:2776)<br /> ...<br /> <br /> The buggy address belongs to the object at ffff888113747800<br /> which belongs to the cache kmalloc-1k of size 1024<br /> The buggy address is located 424 bytes inside of<br /> 1024-byte region [ffff888113747800, ffff888113747c00)<br /> <br /> The buggy address belongs to the physical page:<br /> page:00000000b3fe6c7c refcount:1 mapcount:0 mapping:0000000000000000<br /> index:0x0 pfn:0x113740<br /> head:00000000b3fe6c7c order:3 compound_mapcount:0 subpages_mapcount:0<br /> compound_pincount:0<br /> anon flags: 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff)<br /> raw: 0017ffffc0010200 ffff888100042dc0 0000000000000000 dead000000000001<br /> raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffff888113747880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ffff888113747900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> &gt; ffff888113747980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ^<br /> ffff888113747a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ffff888113747a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ==================================================================<br /> Disabling lock debugging due to kernel taint

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: iscsi_tcp: Fix UAF during login when accessing the shost ipaddress<br /> <br /> If during iscsi_sw_tcp_session_create() iscsi_tcp_r2tpool_alloc() fails,<br /> userspace could be accessing the host&amp;#39;s ipaddress attr. If we then free the<br /> session via iscsi_session_teardown() while userspace is still accessing the<br /> session we will hit a use after free bug.<br /> <br /> Set the tcp_sw_host-&gt;session after we have completed session creation and<br /> can no longer fail.