Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: vt8500lcdfb: fix missing dma_free_coherent()<br /> <br /> fbi-&gt;fb.screen_buffer is allocated with dma_alloc_coherent() but is not<br /> freed if the error path is reached.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: qcom: q6asm: drop DSP responses for closed data streams<br /> <br /> &amp;#39;Commit a354f030dbce ("ASoC: qcom: q6asm: handle the responses<br /> after closing")&amp;#39; attempted to ignore DSP responses arriving<br /> after a stream had been closed.<br /> <br /> However, those responses were still handled, causing lockups.<br /> <br /> Fix this by unconditionally dropping all DSP responses associated with<br /> closed data streams.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dpaa2-switch: validate num_ifs to prevent out-of-bounds write<br /> <br /> The driver obtains sw_attr.num_ifs from firmware via dpsw_get_attributes()<br /> but never validates it against DPSW_MAX_IF (64). This value controls<br /> iteration in dpaa2_switch_fdb_get_flood_cfg(), which writes port indices<br /> into the fixed-size cfg-&gt;if_id[DPSW_MAX_IF] array. When firmware reports<br /> num_ifs &gt;= 64, the loop can write past the array bounds.<br /> <br /> Add a bound check for num_ifs in dpaa2_switch_init().<br /> <br /> dpaa2_switch_fdb_get_flood_cfg() appends the control interface (port<br /> num_ifs) after all matched ports. When num_ifs == DPSW_MAX_IF and all<br /> ports match the flood filter, the loop fills all 64 slots and the control<br /> interface write overflows by one entry.<br /> <br /> The check uses &gt;= because num_ifs == DPSW_MAX_IF is also functionally<br /> broken.<br /> <br /> build_if_id_bitmap() silently drops any ID &gt;= 64:<br /> if (id[i]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> atm: fore200e: fix use-after-free in tasklets during device removal<br /> <br /> When the PCA-200E or SBA-200E adapter is being detached, the fore200e<br /> is deallocated. However, the tx_tasklet or rx_tasklet may still be running<br /> or pending, leading to use-after-free bug when the already freed fore200e<br /> is accessed again in fore200e_tx_tasklet() or fore200e_rx_tasklet().<br /> <br /> One of the race conditions can occur as follows:<br /> <br /> CPU 0 (cleanup) | CPU 1 (tasklet)<br /> fore200e_pca_remove_one() | fore200e_interrupt()<br /> fore200e_shutdown() | tasklet_schedule()<br /> kfree(fore200e) | fore200e_tx_tasklet()<br /> | fore200e-&gt; // UAF<br /> <br /> Fix this by ensuring tx_tasklet or rx_tasklet is properly canceled before<br /> the fore200e is released. Add tasklet_kill() in fore200e_shutdown() to<br /> synchronize with any pending or running tasklets. Moreover, since<br /> fore200e_reset() could prevent further interrupts or data transfers,<br /> the tasklet_kill() should be placed after fore200e_reset() to prevent<br /> the tasklet from being rescheduled in fore200e_interrupt(). Finally,<br /> it only needs to do tasklet_kill() when the fore200e state is greater<br /> than or equal to FORE200E_STATE_IRQ, since tasklets are uninitialized<br /> in earlier states. In a word, the tasklet_kill() should be placed in<br /> the FORE200E_STATE_IRQ branch within the switch...case structure.<br /> <br /> This bug was identified through static analysis.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Fix out-of-bounds write in kfd_event_page_set()<br /> <br /> The kfd_event_page_set() function writes KFD_SIGNAL_EVENT_LIMIT * 8<br /> bytes via memset without checking the buffer size parameter. This allows<br /> unprivileged userspace to trigger an out-of bounds kernel memory write<br /> by passing a small buffer, leading to potential privilege<br /> escalation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm mpath: Add missing dm_put_device when failing to get scsi dh name<br /> <br /> When commit fd81bc5cca8f ("scsi: device_handler: Return error pointer in<br /> scsi_dh_attached_handler_name()") added code to fail parsing the path if<br /> scsi_dh_attached_handler_name() failed with -ENOMEM, it didn&amp;#39;t clean up<br /> the reference to the path device that had just been taken. Fix this, and<br /> steamline the error paths of parse_path() a little.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: fix nfs4_file refcount leak in nfsd_get_dir_deleg()<br /> <br /> Claude pointed out that there is a nfs4_file refcount leak in<br /> nfsd_get_dir_deleg(). Ensure that the reference to "fp" is released<br /> before returning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: validate user queue size constraints<br /> <br /> Add validation to ensure user queue sizes meet hardware requirements:<br /> - Size must be a power of two for efficient ring buffer wrapping<br /> - Size must be at least AMDGPU_GPU_PAGE_SIZE to prevent undersized allocations<br /> <br /> This prevents invalid configurations that could lead to GPU faults or<br /> unexpected behavior.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: ti: pruss: Fix double free in pruss_clk_mux_setup()<br /> <br /> In the pruss_clk_mux_setup(), the devm_add_action_or_reset() indirectly<br /> calls pruss_of_free_clk_provider(), which calls of_node_put(clk_mux_np)<br /> on the error path. However, after the devm_add_action_or_reset()<br /> returns, the of_node_put(clk_mux_np) is called again, causing a double<br /> free.<br /> <br /> Fix by returning directly, to avoid the duplicate of_node_put().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: consume xmit errors of GSO frames<br /> <br /> udpgro_frglist.sh and udpgro_bench.sh are the flakiest tests<br /> currently in NIPA. They fail in the same exact way, TCP GRO<br /> test stalls occasionally and the test gets killed after 10min.<br /> <br /> These tests use veth to simulate GRO. They attach a trivial<br /> ("return XDP_PASS;") XDP program to the veth to force TSO off<br /> and NAPI on.<br /> <br /> Digging into the failure mode we can see that the connection<br /> is completely stuck after a burst of drops. The sender&amp;#39;s snd_nxt<br /> is at sequence number N [1], but the receiver claims to have<br /> received (rcv_nxt) up to N + 3 * MSS [2]. Last piece of the puzzle<br /> is that senders rtx queue is not empty (let&amp;#39;s say the block in<br /> the rtx queue is at sequence number N - 4 * MSS [3]).<br /> <br /> In this state, sender sends a retransmission from the rtx queue<br /> with a single segment, and sequence numbers N-4*MSS:N-3*MSS [3].<br /> Receiver sees it and responds with an ACK all the way up to<br /> N + 3 * MSS [2]. But sender will reject this ack as TCP_ACK_UNSENT_DATA<br /> because it has no recollection of ever sending data that far out [1].<br /> And we are stuck.<br /> <br /> The root cause is the mess of the xmit return codes. veth returns<br /> an error when it can&amp;#39;t xmit a frame. We end up with a loss event<br /> like this:<br /> <br /> -------------------------------------------------<br /> | GSO super frame 1 | GSO super frame 2 |<br /> |-----------------------------------------------|<br /> | seg | seg | seg | seg | seg | seg | seg | seg |<br /> | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |<br /> -------------------------------------------------<br /> x ok ok | ok ok ok <br /> \\<br /> snd_nxt<br /> <br /> "x" means packet lost by veth, and "ok" means it went thru.<br /> Since veth has TSO disabled in this test it sees individual segments.<br /> Segment 1 is on the retransmit queue and will be resent.<br /> <br /> So why did the sender not advance snd_nxt even tho it clearly did<br /> send up to seg 8? tcp_write_xmit() interprets the return code<br /> from the core to mean that data has not been sent at all. Since<br /> TCP deals with GSO super frames, not individual segment the crux<br /> of the problem is that loss of a single segment can be interpreted<br /> as loss of all. TCP only sees the last return code for the last<br /> segment of the GSO frame (in brackets in the diagram above).<br /> <br /> Of course for the problem to occur we need a setup or a device<br /> without a Qdisc. Otherwise Qdisc layer disconnects the protocol<br /> layer from the device errors completely.<br /> <br /> We have multiple ways to fix this.<br /> <br /> 1) make veth not return an error when it lost a packet.<br /> While this is what I think we did in the past, the issue keeps<br /> reappearing and it&amp;#39;s annoying to debug. The game of whack<br /> a mole is not great.<br /> <br /> 2) fix the damn return codes<br /> We only talk about NETDEV_TX_OK and NETDEV_TX_BUSY in the<br /> documentation, so maybe we should make the return code from<br /> ndo_start_xmit() a boolean. I like that the most, but perhaps<br /> some ancient, not-really-networking protocol would suffer.<br /> <br /> 3) make TCP ignore the errors<br /> It is not entirely clear to me what benefit TCP gets from<br /> interpreting the result of ip_queue_xmit()? Specifically once<br /> the connection is established and we&amp;#39;re pushing data - packet<br /> loss is just packet loss?<br /> <br /> 4) this fix<br /> Ignore the rc in the Qdisc-less+GSO case, since it&amp;#39;s unreliable.<br /> We already always return OK in the TCQ_F_CAN_BYPASS case.<br /> In the Qdisc-less case let&amp;#39;s be a bit more conservative and only<br /> mask the GSO errors. This path is taken by non-IP-"networks"<br /> like CAN, MCTP etc, so we could regress some ancient thing.<br /> This is the simplest, but also maybe the hackiest fix?<br /> <br /> Similar fix has been proposed by Eric in the past but never committed<br /> because original reporter was working with an OOT driver and wasn&amp;#39;t<br /> providing feedback (see Link).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netconsole: avoid OOB reads, msg is not nul-terminated<br /> <br /> msg passed to netconsole from the console subsystem is not guaranteed<br /> to be nul-terminated. Before recent<br /> commit 7eab73b18630 ("netconsole: convert to NBCON console infrastructure")<br /> the message would be placed in printk_shared_pbufs, a static global<br /> buffer, so KASAN had harder time catching OOB accesses. Now we see:<br /> <br /> printk: console [netcon_ext0] enabled<br /> BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240<br /> Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594<br /> <br /> CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9<br /> Call Trace:<br /> kasan_report+0xe4/0x120<br /> string+0x1f7/0x240<br /> vsnprintf+0x655/0xba0<br /> scnprintf+0xba/0x120<br /> netconsole_write+0x3fe/0xa10<br /> nbcon_emit_next_record+0x46e/0x860<br /> nbcon_kthread_func+0x623/0x750<br /> <br /> Allocated by task 1:<br /> nbcon_alloc+0x1ea/0x450<br /> register_console+0x26b/0xe10<br /> init_netconsole+0xbb0/0xda0<br /> <br /> The buggy address belongs to the object at ffff88813b6d4000<br /> which belongs to the cache kmalloc-4k of size 4096<br /> The buggy address is located 0 bytes to the right of<br /> allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: fix potential race in tcp_v6_syn_recv_sock()<br /> <br /> Code in tcp_v6_syn_recv_sock() after the call to tcp_v4_syn_recv_sock()<br /> is done too late.<br /> <br /> After tcp_v4_syn_recv_sock(), the child socket is already visible<br /> from TCP ehash table and other cpus might use it.<br /> <br /> Since newinet-&gt;pinet6 is still pointing to the listener ipv6_pinfo<br /> bad things can happen as syzbot found.<br /> <br /> Move the problematic code in tcp_v6_mapped_child_init()<br /> and call this new helper from tcp_v4_syn_recv_sock() before<br /> the ehash insertion.<br /> <br /> This allows the removal of one tcp_sync_mss(), since<br /> tcp_v4_syn_recv_sock() will call it with the correct<br /> context.