Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-fc: release admin tagset if init fails<br /> <br /> nvme_fabrics creates an NVMe/FC controller in following path:<br /> <br /> nvmf_dev_write()<br /> -&gt; nvmf_create_ctrl()<br /> -&gt; nvme_fc_create_ctrl()<br /> -&gt; nvme_fc_init_ctrl()<br /> <br /> nvme_fc_init_ctrl() allocates the admin blk-mq resources right after<br /> nvme_add_ctrl() succeeds. If any of the subsequent steps fail (changing<br /> the controller state, scheduling connect work, etc.), we jump to the<br /> fail_ctrl path, which tears down the controller references but never<br /> frees the admin queue/tag set. The leaked blk-mq allocations match the<br /> kmemleak report seen during blktests nvme/fc.<br /> <br /> Check ctrl-&gt;ctrl.admin_tagset in the fail_ctrl path and call<br /> nvme_remove_admin_tag_set() when it is set so that all admin queue<br /> allocations are reclaimed whenever controller setup aborts.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gve: Fix stats report corruption on queue count change<br /> <br /> The driver and the NIC share a region in memory for stats reporting.<br /> The NIC calculates its offset into this region based on the total size<br /> of the stats region and the size of the NIC&amp;#39;s stats.<br /> <br /> When the number of queues is changed, the driver&amp;#39;s stats region is<br /> resized. If the queue count is increased, the NIC can write past<br /> the end of the allocated stats region, causing memory corruption.<br /> If the queue count is decreased, there is a gap between the driver<br /> and NIC stats, leading to incorrect stats reporting.<br /> <br /> This change fixes the issue by allocating stats region with maximum<br /> size, and the offset calculation for NIC stats is changed to match<br /> with the calculation of the NIC.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/zcrx: fix page array leak<br /> <br /> d9f595b9a65e ("io_uring/zcrx: fix leaking pages on sg init fail") fixed<br /> a page leakage but didn&amp;#39;t free the page array, release it as well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: only call xf{array,blob}_destroy if we have a valid pointer<br /> <br /> Only call the xfarray and xfblob destructor if we have a valid pointer,<br /> and be sure to null out that pointer afterwards. Note that this patch<br /> fixes a large number of commits, most of which were merged between 6.9<br /> and 6.10.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: gro: fix outer network offset<br /> <br /> The udp GRO complete stage assumes that all the packets inserted the RX<br /> have the `encapsulation` flag zeroed. Such assumption is not true, as a<br /> few H/W NICs can set such flag when H/W offloading the checksum for<br /> an UDP encapsulated traffic, the tun driver can inject GSO packets with<br /> UDP encapsulation and the problematic layout can also be created via<br /> a veth based setup.<br /> <br /> Due to the above, in the problematic scenarios, udp4_gro_complete() uses<br /> the wrong network offset (inner instead of outer) to compute the outer<br /> UDP header pseudo checksum, leading to csum validation errors later on<br /> in packet processing.<br /> <br /> Address the issue always clearing the encapsulation flag at GRO completion<br /> time. Such flag will be set again as needed for encapsulated packets by<br /> udp_gro_complete().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: liquidio: Fix off-by-one error in VF setup_nic_devices() cleanup<br /> <br /> In setup_nic_devices(), the initialization loop jumps to the label<br /> setup_nic_dev_free on failure. The current cleanup loop while(i--)<br /> skip the failing index i, causing a memory leak.<br /> <br /> Fix this by changing the loop to iterate from the current index i<br /> down to 0.<br /> <br /> Compile tested only. Issue found using code review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: liquidio: Fix off-by-one error in PF setup_nic_devices() cleanup<br /> <br /> In setup_nic_devices(), the initialization loop jumps to the label<br /> setup_nic_dev_free on failure. The current cleanup loop while(i--)<br /> skip the failing index i, causing a memory leak.<br /> <br /> Fix this by changing the loop to iterate from the current index i<br /> down to 0.<br /> <br /> Also, decrement i in the devlink_alloc failure path to point to the<br /> last successfully allocated index.<br /> <br /> Compile tested only. Issue found using code review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: get rid of the xchk_xfile_*_descr calls<br /> <br /> The xchk_xfile_*_descr macros call kasprintf, which can fail to allocate<br /> memory if the formatted string is larger than 16 bytes (or whatever the<br /> nofail guarantees are nowadays). Some of them could easily exceed that,<br /> and Jiaming Zhang found a few places where that can happen with syzbot.<br /> <br /> The descriptions are debugging aids and aren&amp;#39;t required to be unique, so<br /> let&amp;#39;s just pass in static strings and eliminate this path to failure.<br /> Note this patch touches a number of commits, most of which were merged<br /> between 6.6 and 6.14.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: add proper RCU protection to /proc/net/ptype<br /> <br /> Yin Fengwei reported an RCU stall in ptype_seq_show() and provided<br /> a patch.<br /> <br /> Real issue is that ptype_seq_next() and ptype_seq_show() violate<br /> RCU rules.<br /> <br /> ptype_seq_show() runs under rcu_read_lock(), and reads pt-&gt;dev<br /> to get device name without any barrier.<br /> <br /> At the same time, concurrent writers can remove a packet_type structure<br /> (which is correctly freed after an RCU grace period) and clear pt-&gt;dev<br /> without an RCU grace period.<br /> <br /> Define ptype_iter_state to carry a dev pointer along seq_net_private:<br /> <br /> struct ptype_iter_state {<br /> struct seq_net_private p;<br /> struct net_device *dev; // added in this patch<br /> };<br /> <br /> We need to record the device pointer in ptype_get_idx() and<br /> ptype_seq_next() so that ptype_seq_show() is safe against<br /> concurrent pt-&gt;dev changes.<br /> <br /> We also need to add full RCU protection in ptype_seq_next().<br /> (Missing READ_ONCE() when reading list.next values)<br /> <br /> Many thanks to Dong Chenchen for providing a repro.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: dvb-core: fix wrong reinitialization of ringbuffer on reopen<br /> <br /> dvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the<br /> DVR device. dvb_ringbuffer_init() calls init_waitqueue_head(), which<br /> reinitializes the waitqueue list head to empty.<br /> <br /> Since dmxdev-&gt;dvr_buffer.queue is a shared waitqueue (all opens of the<br /> same DVR device share it), this orphans any existing waitqueue entries<br /> from io_uring poll or epoll, leaving them with stale prev/next pointers<br /> while the list head is reset to {self, self}.<br /> <br /> The waitqueue and spinlock in dvr_buffer are already properly<br /> initialized once in dvb_dmxdev_init(). The open path only needs to<br /> reset the buffer data pointer, size, and read/write positions.<br /> <br /> Replace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct<br /> assignment of data/size and a call to dvb_ringbuffer_reset(), which<br /> properly resets pread, pwrite, and error with correct memory ordering<br /> without touching the waitqueue or spinlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Enable exception fixup for specific ADE subcode<br /> <br /> This patch allows the LoongArch BPF JIT to handle recoverable memory<br /> access errors generated by BPF_PROBE_MEM* instructions.<br /> <br /> When a BPF program performs memory access operations, the instructions<br /> it executes may trigger ADEM exceptions. The kernel’s built-in BPF<br /> exception table mechanism (EX_TYPE_BPF) will generate corresponding<br /> exception fixup entries in the JIT compilation phase; however, the<br /> architecture-specific trap handling function needs to proactively call<br /> the common fixup routine to achieve exception recovery.<br /> <br /> do_ade(): fix EX_TYPE_BPF memory access exceptions for BPF programs,<br /> ensure safe execution.<br /> <br /> Relevant test cases: illegal address access tests in module_attach and<br /> subprogs_extable of selftests/bpf.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: check for deleted cursors when revalidating two btrees<br /> <br /> The free space and inode btree repair functions will rebuild both btrees<br /> at the same time, after which it needs to evaluate both btrees to<br /> confirm that the corruptions are gone.<br /> <br /> However, Jiaming Zhang ran syzbot and produced a crash in the second<br /> xchk_allocbt call. His root-cause analysis is as follows (with minor<br /> corrections):<br /> <br /> In xrep_revalidate_allocbt(), xchk_allocbt() is called twice (first<br /> for BNOBT, second for CNTBT). The cause of this issue is that the<br /> first call nullified the cursor required by the second call.<br /> <br /> Let&amp;#39;s first enter xrep_revalidate_allocbt() via following call chain:<br /> <br /> xfs_file_ioctl() -&gt;<br /> xfs_ioc_scrubv_metadata() -&gt;<br /> xfs_scrub_metadata() -&gt;<br /> `sc-&gt;ops-&gt;repair_eval(sc)` -&gt;<br /> xrep_revalidate_allocbt()<br /> <br /> xchk_allocbt() is called twice in this function. In the first call:<br /> <br /> /* Note that sc-&gt;sm-&gt;sm_type is XFS_SCRUB_TYPE_BNOPT now */<br /> xchk_allocbt() -&gt;<br /> xchk_btree() -&gt;<br /> `bs-&gt;scrub_rec(bs, recp)` -&gt;<br /> xchk_allocbt_rec() -&gt;<br /> xchk_allocbt_xref() -&gt;<br /> xchk_allocbt_xref_other()<br /> <br /> since sm_type is XFS_SCRUB_TYPE_BNOBT, pur is set to &amp;sc-&gt;sa.cnt_cur.<br /> Kernel called xfs_alloc_get_rec() and returned -EFSCORRUPTED. Call<br /> chain:<br /> <br /> xfs_alloc_get_rec() -&gt;<br /> xfs_btree_get_rec() -&gt;<br /> xfs_btree_check_block() -&gt;<br /> (XFS_IS_CORRUPT || XFS_TEST_ERROR), the former is false and the latter<br /> is true, return -EFSCORRUPTED. This should be caused by<br /> ioctl$XFS_IOC_ERROR_INJECTION I guess.<br /> <br /> Back to xchk_allocbt_xref_other(), after receiving -EFSCORRUPTED from<br /> xfs_alloc_get_rec(), kernel called xchk_should_check_xref(). In this<br /> function, *curpp (points to sc-&gt;sa.cnt_cur) is nullified.<br /> <br /> Back to xrep_revalidate_allocbt(), since sc-&gt;sa.cnt_cur has been<br /> nullified, it then triggered null-ptr-deref via xchk_allocbt() (second<br /> call) -&gt; xchk_btree().<br /> <br /> So. The bnobt revalidation failed on a cross-reference attempt, so we<br /> deleted the cntbt cursor, and then crashed when we tried to revalidate<br /> the cntbt. Therefore, check for a null cntbt cursor before that<br /> revalidation, and mark the repair incomplete. Also we can ignore the<br /> second tree entirely if the first tree was rebuilt but is already<br /> corrupt.<br /> <br /> Apply the same fix to xrep_revalidate_iallocbt because it has the same<br /> problem.