Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/sysfs-scheme: cleanup access_pattern subdirs on scheme dir setup failure<br /> <br /> When a DAMOS-scheme DAMON sysfs directory setup fails after setup of<br /> access_pattern/ directory, subdirectories of access_pattern/ directory are<br /> not cleaned up. As a result, DAMON sysfs interface is nearly broken until<br /> the system reboots, and the memory for the unremoved directory is leaked.<br /> <br /> Cleanup the directories under such failures.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, test_run: Subtract size of xdp_frame from allowed metadata size<br /> <br /> The xdp_frame structure takes up part of the XDP frame headroom,<br /> limiting the size of the metadata. However, in bpf_test_run, we don&amp;#39;t<br /> take this into account, which makes it possible for userspace to supply<br /> a metadata size that is too large (taking up the entire headroom).<br /> <br /> If userspace supplies such a large metadata size in live packet mode,<br /> the xdp_update_frame_from_buff() call in xdp_test_run_init_page() call<br /> will fail, after which packet transmission proceeds with an<br /> uninitialised frame structure, leading to the usual Bad Stuff.<br /> <br /> The commit in the Fixes tag fixed a related bug where the second check<br /> in xdp_update_frame_from_buff() could fail, but did not add any<br /> additional constraints on the metadata size. Complete the fix by adding<br /> an additional check on the metadata size. Reorder the checks slightly to<br /> make the logic clearer and add a comment.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: send: check for inline extents in range_is_hole_in_parent()<br /> <br /> Before accessing the disk_bytenr field of a file extent item we need<br /> to check if we are dealing with an inline extent.<br /> This is because for inline extents their data starts at the offset of<br /> the disk_bytenr field. So accessing the disk_bytenr<br /> means we are accessing inline data or in case the inline data is less<br /> than 8 bytes we can actually cause an invalid<br /> memory access if this inline extent item is the first item in the leaf<br /> or access metadata from other items.

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