Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: endpoint: Fix swapped parameters in pci_{primary/secondary}_epc_epf_unlink() functions<br /> <br /> struct configfs_item_operations callbacks are defined like the following:<br /> <br /> int (*allow_link)(struct config_item *src, struct config_item *target);<br /> void (*drop_link)(struct config_item *src, struct config_item *target);<br /> <br /> While pci_primary_epc_epf_link() and pci_secondary_epc_epf_link() specify<br /> the parameters in the correct order, pci_primary_epc_epf_unlink() and<br /> pci_secondary_epc_epf_unlink() specify the parameters in the wrong order,<br /> leading to the below kernel crash when using the unlink command in<br /> configfs:<br /> <br /> Unable to handle kernel paging request at virtual address 0000000300000857<br /> Mem abort info:<br /> ...<br /> pc : string+0x54/0x14c<br /> lr : vsnprintf+0x280/0x6e8<br /> ...<br /> string+0x54/0x14c<br /> vsnprintf+0x280/0x6e8<br /> vprintk_default+0x38/0x4c<br /> vprintk+0xc4/0xe0<br /> pci_epf_unbind+0xdc/0x108<br /> configfs_unlink+0xe0/0x208+0x44/0x74<br /> vfs_unlink+0x120/0x29c<br /> __arm64_sys_unlinkat+0x3c/0x90<br /> invoke_syscall+0x48/0x134<br /> do_el0_svc+0x1c/0x30prop.0+0xd0/0xf0<br /> <br /> [mani: cced stable, changed commit message as per https://lore.kernel.org/linux-pci/aV9joi3jF1R6ca02@ryzen]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> APEI/GHES: ARM processor Error: don&amp;#39;t go past allocated memory<br /> <br /> If the BIOS generates a very small ARM Processor Error, or<br /> an incomplete one, the current logic will fail to deferrence<br /> <br /> err-&gt;section_length<br /> and<br /> ctx_info-&gt;size<br /> <br /> Add checks to avoid that. With such changes, such GHESv2<br /> records won&amp;#39;t cause OOPSes like this:<br /> <br /> [ 1.492129] Internal error: Oops: 0000000096000005 [#1] SMP<br /> [ 1.495449] Modules linked in:<br /> [ 1.495820] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.18.0-rc1-00017-gabadcc3553dd-dirty #18 PREEMPT<br /> [ 1.496125] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022<br /> [ 1.496433] Workqueue: kacpi_notify acpi_os_execute_deferred<br /> [ 1.496967] pstate: 814000c5 (Nzcv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> [ 1.497199] pc : log_arm_hw_error+0x5c/0x200<br /> [ 1.497380] lr : ghes_handle_arm_hw_error+0x94/0x220<br /> <br /> 0xffff8000811c5324 is in log_arm_hw_error (../drivers/ras/ras.c:75).<br /> 70 err_info = (struct cper_arm_err_info *)(err + 1);<br /> 71 ctx_info = (struct cper_arm_ctx_info *)(err_info + err-&gt;err_info_num);<br /> 72 ctx_err = (u8 *)ctx_info;<br /> 73<br /> 74 for (n = 0; n context_info_num; n++) {<br /> 75 sz = sizeof(struct cper_arm_ctx_info) + ctx_info-&gt;size;<br /> 76 ctx_info = (struct cper_arm_ctx_info *)((long)ctx_info + sz);<br /> 77 ctx_len += sz;<br /> 78 }<br /> 79<br /> <br /> and similar ones while trying to access section_length on an<br /> error dump with too small size.<br /> <br /> [ rjw: Subject tweaks ]

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix "scheduling while atomic" in IPsec MAC address query<br /> <br /> Fix a "scheduling while atomic" bug in mlx5e_ipsec_init_macs() by<br /> replacing mlx5_query_mac_address() with ether_addr_copy() to get the<br /> local MAC address directly from netdev-&gt;dev_addr.<br /> <br /> The issue occurs because mlx5_query_mac_address() queries the hardware<br /> which involves mlx5_cmd_exec() that can sleep, but it is called from<br /> the mlx5e_ipsec_handle_event workqueue which runs in atomic context.<br /> <br /> The MAC address is already available in netdev-&gt;dev_addr, so no need<br /> to query hardware. This avoids the sleeping call and resolves the bug.<br /> <br /> Call trace:<br /> BUG: scheduling while atomic: kworker/u112:2/69344/0x00000200<br /> __schedule+0x7ab/0xa20<br /> schedule+0x1c/0xb0<br /> schedule_timeout+0x6e/0xf0<br /> __wait_for_common+0x91/0x1b0<br /> cmd_exec+0xa85/0xff0 [mlx5_core]<br /> mlx5_cmd_exec+0x1f/0x50 [mlx5_core]<br /> mlx5_query_nic_vport_mac_address+0x7b/0xd0 [mlx5_core]<br /> mlx5_query_mac_address+0x19/0x30 [mlx5_core]<br /> mlx5e_ipsec_init_macs+0xc1/0x720 [mlx5_core]<br /> mlx5e_ipsec_build_accel_xfrm_attrs+0x422/0x670 [mlx5_core]<br /> mlx5e_ipsec_handle_event+0x2b9/0x460 [mlx5_core]<br /> process_one_work+0x178/0x2e0<br /> worker_thread+0x2ea/0x430

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 /> 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 /> 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 /> ceph: do not propagate page array emplacement errors as batch errors<br /> <br /> When fscrypt is enabled, move_dirty_folio_in_page_array() may fail<br /> because it needs to allocate bounce buffers to store the encrypted<br /> versions of each folio. Each folio beyond the first allocates its bounce<br /> buffer with GFP_NOWAIT. Failures are common (and expected) under this<br /> allocation mode; they should flush (not abort) the batch.<br /> <br /> However, ceph_process_folio_batch() uses the same `rc` variable for its<br /> own return code and for capturing the return codes of its routine calls;<br /> failing to reset `rc` back to 0 results in the error being propagated<br /> out to the main writeback loop, which cannot actually tolerate any<br /> errors here: once `ceph_wbc.pages` is allocated, it must be passed to<br /> ceph_submit_write() to be freed. If it survives until the next iteration<br /> (e.g. due to the goto being followed), ceph_allocate_page_array()&amp;#39;s<br /> BUG_ON() will oops the worker.<br /> <br /> Note that this failure mode is currently masked due to another bug<br /> (addressed next in this series) that prevents multiple encrypted folios<br /> from being selected for the same write.<br /> <br /> For now, just reset `rc` when redirtying the folio to prevent errors in<br /> move_dirty_folio_in_page_array() from propagating. Note that<br /> move_dirty_folio_in_page_array() is careful never to return errors on<br /> the first folio, so there is no need to check for that. After this<br /> change, ceph_process_folio_batch() no longer returns errors; its only<br /> remaining failure indicator is `locked_pages == 0`, which the caller<br /> already handles correctly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: delete attr leaf freemap entries when empty<br /> <br /> Back in commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size<br /> underflow"), Brian Foster observed that it&amp;#39;s possible for a small<br /> freemap at the end of the end of the xattr entries array to experience<br /> a size underflow when subtracting the space consumed by an expansion of<br /> the entries array. There are only three freemap entries, which means<br /> that it is not a complete index of all free space in the leaf block.<br /> <br /> This code can leave behind a zero-length freemap entry with a nonzero<br /> base. Subsequent setxattr operations can increase the base up to the<br /> point that it overlaps with another freemap entry. This isn&amp;#39;t in and of<br /> itself a problem because the code in _leaf_add that finds free space<br /> ignores any freemap entry with zero size.<br /> <br /> However, there&amp;#39;s another bug in the freemap update code in _leaf_add,<br /> which is that it fails to update a freemap entry that begins midway<br /> through the xattr entry that was just appended to the array. That can<br /> result in the freemap containing two entries with the same base but<br /> different sizes (0 for the "pushed-up" entry, nonzero for the entry<br /> that&amp;#39;s actually tracking free space). A subsequent _leaf_add can then<br /> allocate xattr namevalue entries on top of the entries array, leading to<br /> data loss. But fixing that is for later.<br /> <br /> For now, eliminate the possibility of confusion by zeroing out the base<br /> of any freemap entry that has zero size. Because the freemap is not<br /> intended to be a complete index of free space, a subsequent failure to<br /> find any free space for a new xattr will trigger block compaction, which<br /> regenerates the freemap.<br /> <br /> It looks like this bug has been in the codebase for quite a long time.