Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: zlib: fix the folio leak on S390 hardware acceleration<br /> <br /> [BUG]<br /> After commit aa60fe12b4f4 ("btrfs: zlib: refactor S390x HW acceleration<br /> buffer preparation"), we no longer release the folio of the page cache<br /> of folio returned by btrfs_compress_filemap_get_folio() for S390<br /> hardware acceleration path.<br /> <br /> [CAUSE]<br /> Before that commit, we call kumap_local() and folio_put() after handling<br /> each folio.<br /> <br /> Although the timing is not ideal (it release previous folio at the<br /> beginning of the loop, and rely on some extra cleanup out of the loop),<br /> it at least handles the folio release correctly.<br /> <br /> Meanwhile the refactored code is easier to read, it lacks the call to<br /> release the filemap folio.<br /> <br /> [FIX]<br /> Add the missing folio_put() for copy_data_into_buffer().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet: fix race in nvmet_bio_done() leading to NULL pointer dereference<br /> <br /> There is a race condition in nvmet_bio_done() that can cause a NULL<br /> pointer dereference in blk_cgroup_bio_start():<br /> <br /> 1. nvmet_bio_done() is called when a bio completes<br /> 2. nvmet_req_complete() is called, which invokes req-&gt;ops-&gt;queue_response(req)<br /> 3. The queue_response callback can re-queue and re-submit the same request<br /> 4. The re-submission reuses the same inline_bio from nvmet_req<br /> 5. Meanwhile, nvmet_req_bio_put() (called after nvmet_req_complete)<br /> invokes bio_uninit() for inline_bio, which sets bio-&gt;bi_blkg to NULL<br /> 6. The re-submitted bio enters submit_bio_noacct_nocheck()<br /> 7. blk_cgroup_bio_start() dereferences bio-&gt;bi_blkg, causing a crash:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000028<br /> #PF: supervisor read access in kernel mode<br /> RIP: 0010:blk_cgroup_bio_start+0x10/0xd0<br /> Call Trace:<br /> submit_bio_noacct_nocheck+0x44/0x250<br /> nvmet_bdev_execute_rw+0x254/0x370 [nvmet]<br /> process_one_work+0x193/0x3c0<br /> worker_thread+0x281/0x3a0<br /> <br /> Fix this by reordering nvmet_bio_done() to call nvmet_req_bio_put()<br /> BEFORE nvmet_req_complete(). This ensures the bio is cleaned up before<br /> the request can be re-submitted, preventing the race condition.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/bridge: synopsys: dw-dp: fix error paths of dw_dp_bind<br /> <br /> Fix several issues in dw_dp_bind() error handling:<br /> <br /> 1. Missing return after drm_bridge_attach() failure - the function<br /> continued execution instead of returning an error.<br /> <br /> 2. Resource leak: drm_dp_aux_register() is not a devm function, so<br /> drm_dp_aux_unregister() must be called on all error paths after<br /> aux registration succeeds. This affects errors from:<br /> - drm_bridge_attach()<br /> - phy_init()<br /> - devm_add_action_or_reset()<br /> - platform_get_irq()<br /> - devm_request_threaded_irq()<br /> <br /> 3. Bug fix: platform_get_irq() returns the IRQ number or a negative<br /> error code, but the error path was returning ERR_PTR(ret) instead<br /> of ERR_PTR(dp-&gt;irq).<br /> <br /> Use a goto label for cleanup to ensure consistent error handling.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath10k: fix dma_free_coherent() pointer<br /> <br /> dma_alloc_coherent() allocates a DMA mapped buffer and stores the<br /> addresses in XXX_unaligned fields. Those should be reused when freeing<br /> the buffer rather than the aligned addresses.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> slab: fix kmalloc_nolock() context check for PREEMPT_RT<br /> <br /> On PREEMPT_RT kernels, local_lock becomes a sleeping lock. The current<br /> check in kmalloc_nolock() only verifies we&amp;#39;re not in NMI or hard IRQ<br /> context, but misses the case where preemption is disabled.<br /> <br /> When a BPF program runs from a tracepoint with preemption disabled<br /> (preempt_count &gt; 0), kmalloc_nolock() proceeds to call<br /> local_lock_irqsave() which attempts to acquire a sleeping lock,<br /> triggering:<br /> <br /> BUG: sleeping function called from invalid context<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 6128<br /> preempt_count: 2, expected: 0<br /> <br /> Fix this by checking !preemptible() on PREEMPT_RT, which directly<br /> expresses the constraint that we cannot take a sleeping lock when<br /> preemption is disabled. This encompasses the previous checks for NMI<br /> and hard IRQ contexts while also catching cases where preemption is<br /> disabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix dma_free_coherent() pointer<br /> <br /> dma_alloc_coherent() allocates a DMA mapped buffer and stores the<br /> addresses in XXX_unaligned fields. Those should be reused when freeing<br /> the buffer rather than the aligned addresses.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: reset sparse-read state in osd_fault()<br /> <br /> When a fault occurs, the connection is abandoned, reestablished, and any<br /> pending operations are retried. The OSD client tracks the progress of a<br /> sparse-read reply using a separate state machine, largely independent of<br /> the messenger&amp;#39;s state.<br /> <br /> If a connection is lost mid-payload or the sparse-read state machine<br /> returns an error, the sparse-read state is not reset. The OSD client<br /> will then interpret the beginning of a new reply as the continuation of<br /> the old one. If this makes the sparse-read machinery enter a failure<br /> state, it may never recover, producing loops like:<br /> <br /> libceph: [0] got 0 extents<br /> libceph: data len 142248331 != extent len 0<br /> libceph: osd0 (1)...:6801 socket error on read<br /> libceph: data len 142248331 != extent len 0<br /> libceph: osd0 (1)...:6801 socket error on read<br /> <br /> Therefore, reset the sparse-read state in osd_fault(), ensuring retries<br /> start from a clean state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> of: unittest: Fix memory leak in unittest_data_add()<br /> <br /> In unittest_data_add(), if of_resolve_phandles() fails, the allocated<br /> unittest_data is not freed, leading to a memory leak.<br /> <br /> Fix this by using scope-based cleanup helper __free(kfree) for automatic<br /> resource cleanup. This ensures unittest_data is automatically freed when<br /> it goes out of scope in error paths.<br /> <br /> For the success path, use retain_and_null_ptr() to transfer ownership<br /> of the memory to the device tree and prevent double freeing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Add recursion protection in kernel stack trace recording<br /> <br /> A bug was reported about an infinite recursion caused by tracing the rcu<br /> events with the kernel stack trace trigger enabled. The stack trace code<br /> called back into RCU which then called the stack trace again.<br /> <br /> Expand the ftrace recursion protection to add a set of bits to protect<br /> events from recursion. Each bit represents the context that the event is<br /> in (normal, softirq, interrupt and NMI).<br /> <br /> Have the stack trace code use the interrupt context to protect against<br /> recursion.<br /> <br /> Note, the bug showed an issue in both the RCU code as well as the tracing<br /> stacktrace code. This only handles the tracing stack trace side of the<br /> bug. The RCU fix will be handled separately.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conncount: update last_gc only when GC has been performed<br /> <br /> Currently last_gc is being updated everytime a new connection is<br /> tracked, that means that it is updated even if a GC wasn&amp;#39;t performed.<br /> With a sufficiently high packet rate, it is possible to always bypass<br /> the GC, causing the list to grow infinitely.<br /> <br /> Update the last_gc value only when a GC has been actually performed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix early read unlock of page with EOF in middle<br /> <br /> The read result collection for buffered reads seems to run ahead of the<br /> completion of subrequests under some circumstances, as can be seen in the<br /> following log snippet:<br /> <br /> 9p_client_res: client 18446612686390831168 response P9_TREAD tag 0 err 0<br /> ...<br /> netfs_sreq: R=00001b55[1] DOWN TERM f=192 s=0 5fb2/5fb2 s=5 e=0<br /> ...<br /> netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2<br /> netfs_folio: i=157f3 ix=00004-00004 read-done<br /> netfs_folio: i=157f3 ix=00004-00004 read-unlock<br /> netfs_collect_folio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2<br /> netfs_folio: i=157f3 ix=00005-00005 read-done<br /> netfs_folio: i=157f3 ix=00005-00005 read-unlock<br /> ...<br /> netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff<br /> netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c<br /> netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff<br /> netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=8<br /> ...<br /> netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0<br /> netfs_sreq: R=00001b55[2] ZERO TERM f=102 s=5fb2 4e/4e s=5 e=0<br /> <br /> The &amp;#39;cto=5fb2&amp;#39; indicates the collected file pos we&amp;#39;ve collected results to<br /> so far - but we still have 0x4e more bytes to go - so we shouldn&amp;#39;t have<br /> collected folio ix=00005 yet. The &amp;#39;ZERO&amp;#39; subreq that clears the tail<br /> happens after we unlock the folio, allowing the application to see the<br /> uncleared tail through mmap.<br /> <br /> The problem is that netfs_read_unlock_folios() will unlock a folio in which<br /> the amount of read results collected hits EOF position - but the ZERO<br /> subreq lies beyond that and so happens after.<br /> <br /> Fix this by changing the end check to always be the end of the folio and<br /> never the end of the file.<br /> <br /> In the future, I should look at clearing to the end of the folio here rather<br /> than adding a ZERO subreq to do this. On the other hand, the ZERO subreq can<br /> run in parallel with an async READ subreq. Further, the ZERO subreq may still<br /> be necessary to, say, handle extents in a ceph file that don&amp;#39;t have any<br /> backing store and are thus implicitly all zeros.<br /> <br /> This can be reproduced by creating a file, the size of which doesn&amp;#39;t align<br /> to a page boundary, e.g. 24998 (0x5fb2) bytes and then doing something<br /> like:<br /> <br /> xfs_io -c "mmap -r 0 0x6000" -c "madvise -d 0 0x6000" \<br /> -c "mread -v 0 0x6000" /xfstest.test/x<br /> <br /> The last 0x4e bytes should all be 00, but if the tail hasn&amp;#39;t been cleared<br /> yet, you may see rubbish there. This can be reproduced with kafs by<br /> modifying the kernel to disable the call to netfs_read_subreq_progress()<br /> and to stop afs_issue_read() from doing the async call for NETFS_READAHEAD.<br /> Reproduction can be made easier by inserting an mdelay(100) in<br /> netfs_issue_read() for the ZERO-subreq case.<br /> <br /> AFS and CIFS are normally unlikely to show this as they dispatch READ ops<br /> asynchronously, which allows the ZERO-subreq to finish first. 9P&amp;#39;s READ op is<br /> completely synchronous, so the ZERO-subreq will always happen after. It isn&amp;#39;t<br /> seen all the time, though, because the collection may be done in a worker<br /> thread.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/sva: invalidate stale IOTLB entries for kernel address space<br /> <br /> Introduce a new IOMMU interface to flush IOTLB paging cache entries for<br /> the CPU kernel address space. This interface is invoked from the x86<br /> architecture code that manages combined user and kernel page tables,<br /> specifically before any kernel page table page is freed and reused.<br /> <br /> This addresses the main issue with vfree() which is a common occurrence<br /> and can be triggered by unprivileged users. While this resolves the<br /> primary problem, it doesn&amp;#39;t address some extremely rare case related to<br /> memory unplug of memory that was present as reserved memory at boot, which<br /> cannot be triggered by unprivileged users. The discussion can be found at<br /> the link below.<br /> <br /> Enable SVA on x86 architecture since the IOMMU can now receive<br /> notification to flush the paging cache before freeing the CPU kernel page<br /> table pages.