Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: hda/via: Avoid potential array out-of-bound in add_secret_dac_path()<br /> <br /> snd_hda_get_connections() can return a negative error code.<br /> It may lead to accessing &amp;#39;conn&amp;#39; array at a negative index.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firewire: fix memory leak for payload of request subaction to IEC 61883-1 FCP region<br /> <br /> This patch is fix for Linux kernel v2.6.33 or later.<br /> <br /> For request subaction to IEC 61883-1 FCP region, Linux FireWire subsystem<br /> have had an issue of use-after-free. The subsystem allows multiple<br /> user space listeners to the region, while data of the payload was likely<br /> released before the listeners execute read(2) to access to it for copying<br /> to user space.<br /> <br /> The issue was fixed by a commit 281e20323ab7 ("firewire: core: fix<br /> use-after-free regression in FCP handler"). The object of payload is<br /> duplicated in kernel space for each listener. When the listener executes<br /> ioctl(2) with FW_CDEV_IOC_SEND_RESPONSE request, the object is going to<br /> be released.<br /> <br /> However, it causes memory leak since the commit relies on call of<br /> release_request() in drivers/firewire/core-cdev.c. Against the<br /> expectation, the function is never called due to the design of<br /> release_client_resource(). The function delegates release task<br /> to caller when called with non-NULL fourth argument. The implementation<br /> of ioctl_send_response() is the case. It should release the object<br /> explicitly.<br /> <br /> This commit fixes the bug.

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/i8259: Mark legacy PIC interrupts with IRQ_LEVEL<br /> <br /> Baoquan reported that after triggering a crash the subsequent crash-kernel<br /> fails to boot about half of the time. It triggers a NULL pointer<br /> dereference in the periodic tick code.<br /> <br /> This happens because the legacy timer interrupt (IRQ0) is resent in<br /> software which happens in soft interrupt (tasklet) context. In this context<br /> get_irq_regs() returns NULL which leads to the NULL pointer dereference.<br /> <br /> The reason for the resend is a spurious APIC interrupt on the IRQ0 vector<br /> which is captured and leads to a resend when the legacy timer interrupt is<br /> enabled. This is wrong because the legacy PIC interrupts are level<br /> triggered and therefore should never be resent in software, but nothing<br /> ever sets the IRQ_LEVEL flag on those interrupts, so the core code does not<br /> know about their trigger type.<br /> <br /> Ensure that IRQ_LEVEL is set when the legacy PCI interrupts are set up.

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

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