Vulnerabilities

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.

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.

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 /> platform/x86: hp-bioscfg: Fix kobject warnings for empty attribute names<br /> <br /> The hp-bioscfg driver attempts to register kobjects with empty names when<br /> the HP BIOS returns attributes with empty name strings. This causes<br /> multiple kernel warnings:<br /> <br /> kobject: (00000000135fb5e6): attempted to be registered with empty name!<br /> WARNING: CPU: 14 PID: 3336 at lib/kobject.c:219 kobject_add_internal+0x2eb/0x310<br /> <br /> Add validation in hp_init_bios_buffer_attribute() to check if the<br /> attribute name is empty after parsing it from the WMI buffer. If empty,<br /> log a debug message and skip registration of that attribute, allowing the<br /> module to continue processing other valid attributes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix dead lock while flushing management frames<br /> <br /> Commit [1] converted the management transmission work item into a<br /> wiphy work. Since a wiphy work can only run under wiphy lock<br /> protection, a race condition happens in below scenario:<br /> <br /> 1. a management frame is queued for transmission.<br /> 2. ath12k_mac_op_flush() gets called to flush pending frames associated<br /> with the hardware (i.e, vif being NULL). Then in ath12k_mac_flush()<br /> the process waits for the transmission done.<br /> 3. Since wiphy lock has been taken by the flush process, the transmission<br /> work item has no chance to run, hence the dead lock.<br /> <br /> &gt;From user view, this dead lock results in below issue:<br /> <br /> wlp8s0: authenticate with xxxxxx (local address=xxxxxx)<br /> wlp8s0: send auth to xxxxxx (try 1/3)<br /> wlp8s0: authenticate with xxxxxx (local address=xxxxxx)<br /> wlp8s0: send auth to xxxxxx (try 1/3)<br /> wlp8s0: authenticated<br /> wlp8s0: associate with xxxxxx (try 1/3)<br /> wlp8s0: aborting association with xxxxxx by local choice (Reason: 3=DEAUTH_LEAVING)<br /> ath12k_pci 0000:08:00.0: failed to flush mgmt transmit queue, mgmt pkts pending 1<br /> <br /> The dead lock can be avoided by invoking wiphy_work_flush() to proactively<br /> run the queued work item. Note actually it is already present in<br /> ath12k_mac_op_flush(), however it does not protect the case where vif<br /> being NULL. Hence move it ahead to cover this case as well.<br /> <br /> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dpll: Prevent duplicate registrations<br /> <br /> Modify the internal registration helpers dpll_xa_ref_{dpll,pin}_add()<br /> to reject duplicate registration attempts.<br /> <br /> Previously, if a caller attempted to register the same pin multiple<br /> times (with the same ops, priv, and cookie) on the same device, the core<br /> silently increments the reference count and return success. This behavior<br /> is incorrect because if the caller makes these duplicate registrations<br /> then for the first one dpll_pin_registration is allocated and for others<br /> the associated dpll_pin_ref.refcount is incremented. During the first<br /> unregistration the associated dpll_pin_registration is freed and for<br /> others WARN is fired.<br /> <br /> Fix this by updating the logic to return `-EEXIST` if a matching<br /> registration is found to enforce a strict "register once" policy.