Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/mempolicy: fix memory leaks in weighted_interleave_auto_store()<br /> <br /> weighted_interleave_auto_store() fetches old_wi_state inside the if<br /> (!input) block only. This causes two memory leaks:<br /> <br /> 1. When a user writes "false" and the current mode is already manual,<br /> the function returns early without freeing the freshly allocated<br /> new_wi_state.<br /> <br /> 2. When a user writes "true", old_wi_state stays NULL because the<br /> fetch is skipped entirely. The old state is then overwritten by<br /> rcu_assign_pointer() but never freed, since the cleanup path is<br /> gated on old_wi_state being non-NULL. A user can trigger this<br /> repeatedly by writing "1" in a loop.<br /> <br /> Fix both leaks by moving the old_wi_state fetch before the input check,<br /> making it unconditional. This also allows a unified early return for both<br /> "true" and "false" when the requested mode matches the current mode.<br /> <br /> Reviewed by: Donet Tom

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> greybus: gb-beagleplay: fix sleep in atomic context in hdlc_tx_frames()<br /> <br /> hdlc_append() calls usleep_range() to wait for circular buffer space,<br /> but it is called with tx_producer_lock (a spinlock) held via<br /> hdlc_tx_frames() -&gt; hdlc_append_tx_frame()/hdlc_append_tx_u8()/etc.<br /> Sleeping while holding a spinlock is illegal and can trigger<br /> "BUG: scheduling while atomic".<br /> <br /> Fix this by moving the buffer-space wait out of hdlc_append() and into<br /> hdlc_tx_frames(), before the spinlock is acquired. The new flow:<br /> <br /> 1. Pre-calculate the worst-case encoded frame length.<br /> 2. Wait (with sleep) outside the lock until enough space is available,<br /> kicking the TX consumer work to drain the buffer.<br /> 3. Acquire the spinlock, re-verify space, and write the entire frame<br /> atomically.<br /> <br /> This ensures that sleeping only happens without any lock held, and<br /> that frames are either fully enqueued or not written at all.<br /> <br /> This bug is found by CodeQL static analysis tool (interprocedural<br /> sleep-in-atomic query) and my code review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> inotify: fix watch count leak when fsnotify_add_inode_mark_locked() fails<br /> <br /> When fsnotify_add_inode_mark_locked() fails in inotify_new_watch(),<br /> the error path calls inotify_remove_from_idr() but does not call<br /> dec_inotify_watches() to undo the preceding inc_inotify_watches().<br /> This leaks a watch count, and repeated failures can exhaust the<br /> max_user_watches limit with -ENOSPC even when no watches are active.<br /> <br /> Prior to commit 1cce1eea0aff ("inotify: Convert to using per-namespace<br /> limits"), the watch count was incremented after fsnotify_add_mark_locked()<br /> succeeded, so this path was not affected. The conversion moved<br /> inc_inotify_watches() before the mark insertion without adding the<br /> corresponding rollback.<br /> <br /> Add the missing dec_inotify_watches() call in the error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxgk: Fix potential integer overflow in length check<br /> <br /> Fix potential integer overflow in rxgk_extract_token() when checking the<br /> length of the ticket. Rather than rounding up the value to be tested<br /> (which might overflow), round down the size of the available data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: icmp: validate reply type before using icmp_pointers<br /> <br /> Extended echo replies use ICMP_EXT_ECHOREPLY as the outbound reply type.<br /> That value is outside the range covered by icmp_pointers[], which only<br /> describes the traditional ICMP types up to NR_ICMP_TYPES.<br /> <br /> Avoid consulting icmp_pointers[] for reply types outside that range, and<br /> use array_index_nospec() for the remaining in-range lookup. Normal ICMP<br /> replies keep their existing behavior unchanged.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qrtr: ns: Free the node during ctrl_cmd_bye()<br /> <br /> A node sends the BYE packet when it is about to go down. So the nameserver<br /> should advertise the removal of the node to all remote and local observers<br /> and free the node finally. But currently, the nameserver doesn&amp;#39;t free the<br /> node memory even after processing the BYE packet. This causes the node<br /> memory to leak.<br /> <br /> Hence, remove the node from Xarray list and free the node memory during<br /> both success and failure case of ctrl_cmd_bye().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipmi:ssif: Clean up kthread on errors<br /> <br /> If an error occurs after the ssif kthread is created, but before the<br /> main IPMI code starts the ssif interface, the ssif kthread will not<br /> be stopped.<br /> <br /> So make sure the kthread is stopped on an error condition if it is<br /> running.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio/cdx: Serialize VFIO_DEVICE_SET_IRQS with a per-device mutex<br /> <br /> vfio_cdx_set_msi_trigger() reads vdev-&gt;config_msi and operates on the<br /> vdev-&gt;cdx_irqs array based on its value, but provides no serialization<br /> against concurrent VFIO_DEVICE_SET_IRQS ioctls. Two callers can race<br /> such that one observes config_msi as set while another clears it and<br /> frees cdx_irqs via vfio_cdx_msi_disable(), resulting in a use-after-free<br /> of the cdx_irqs array.<br /> <br /> Add a cdx_irqs_lock mutex to struct vfio_cdx_device and acquire it in<br /> vfio_cdx_set_msi_trigger(), which is the single chokepoint through<br /> which all updates to config_msi, cdx_irqs, and msi_count flow, covering<br /> both the ioctl path and the close-device cleanup path. This keeps the<br /> test of config_msi atomic with the subsequent enable, disable, or<br /> trigger operations.<br /> <br /> Drop the pre-call !cdx_irqs test from vfio_cdx_irqs_cleanup() as part<br /> of this change: the optimization it provided is redundant with the<br /> !config_msi early-return inside vfio_cdx_msi_disable(), and leaving the<br /> test in place would be an unsynchronized read of state the new lock is<br /> meant to protect.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/page_alloc: return NULL early from alloc_frozen_pages_nolock() in NMI on UP<br /> <br /> On UP kernels (!CONFIG_SMP), spin_trylock() is a no-op that<br /> unconditionally succeeds even when the lock is already held. As a<br /> result, alloc_frozen_pages_nolock() called from NMI context can<br /> re-enter rmqueue() and acquire the zone lock that the interrupted<br /> context is already holding, corrupting the freelists.<br /> <br /> With CONFIG_DEBUG_SPINLOCK on UP, the following BUG is triggered with<br /> the slub_kunit test module:<br /> <br /> BUG: spinlock trylock failure on UP on CPU#0, kunit_try_catch/243<br /> [...]<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x3f/0x60<br /> do_raw_spin_trylock+0x41/0x50<br /> _raw_spin_trylock+0x24/0x50<br /> rmqueue.isra.0+0x2a9/0xa70<br /> get_page_from_freelist+0xeb/0x450<br /> alloc_frozen_pages_nolock_noprof+0x111/0x1e0<br /> allocate_slab+0x42a/0x500<br /> ___slab_alloc+0xa7/0x4c0<br /> kmalloc_nolock_noprof+0x164/0x310<br /> [...]<br /> <br /> <br /> Fix this by returning NULL early when invoked from NMI on a UP kernel.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio/cdx: Fix NULL pointer dereference in interrupt trigger path<br /> <br /> Add validation to ensure MSI is configured before accessing cdx_irqs<br /> array in vfio_cdx_set_msi_trigger(). Without this check, userspace<br /> can trigger a NULL pointer dereference by calling VFIO_DEVICE_SET_IRQS<br /> with VFIO_IRQ_SET_DATA_BOOL or VFIO_IRQ_SET_DATA_NONE flags before<br /> ever setting up interrupts via VFIO_IRQ_SET_DATA_EVENTFD.<br /> <br /> The vfio_cdx_msi_enable() function allocates the cdx_irqs array and<br /> sets config_msi to 1 only when called through the EVENTFD path. The<br /> trigger loop (for DATA_BOOL/DATA_NONE) assumed this had already been<br /> done, but there was no enforcement of this call ordering.<br /> <br /> This matches the protection used in the PCI VFIO driver where<br /> vfio_pci_set_msi_trigger() checks irq_is() before the trigger loop.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: nSVM: Triple fault if restore host CR3 fails on nested #VMEXIT<br /> <br /> If loading L1&amp;#39;s CR3 fails on a nested #VMEXIT, nested_svm_vmexit()<br /> returns an error code that is ignored by most callers, and continues to<br /> run L1 with corrupted state. A sane recovery is not possible in this<br /> case, and HW behavior is to cause a shutdown. Inject a triple fault<br /> instead, and do not return early from nested_svm_vmexit(). Continue<br /> cleaning up the vCPU state (e.g. clear pending exceptions), to handle<br /> the failure as gracefully as possible.<br /> <br /> From the APM:<br /> <br /> Upon #VMEXIT, the processor performs the following actions in order to<br /> return to the host execution context:<br /> <br /> ...<br /> <br /> if (illegal host state loaded, or exception while loading host state)<br /> shutdown<br /> else<br /> execute first host instruction following the VMRUN<br /> <br /> Remove the return value of nested_svm_vmexit(), which is mostly<br /> unchecked anyway.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ks8851: Reinstate disabling of BHs around IRQ handler<br /> <br /> If the driver executes ks8851_irq() AND a TX packet has been sent, then<br /> the driver enables TX queue via netif_wake_queue() which schedules TX<br /> softirq to queue packets for this device.<br /> <br /> If CONFIG_PREEMPT_RT=y is set AND a packet has also been received by<br /> the MAC, then ks8851_rx_pkts() calls netdev_alloc_skb_ip_align() to<br /> allocate SKBs for the received packets. If netdev_alloc_skb_ip_align()<br /> is called with BH enabled, then local_bh_enable() at the end of<br /> netdev_alloc_skb_ip_align() will trigger the pending softirq processing,<br /> which may ultimately call the .xmit callback ks8851_start_xmit_par().<br /> The ks8851_start_xmit_par() will try to lock struct ks8851_net_par<br /> .lock spinlock, which is already locked by ks8851_irq() from which<br /> ks8851_start_xmit_par() was called. This leads to a deadlock, which<br /> is reported by the kernel, including a trace listed below.<br /> <br /> If CONFIG_PREEMPT_RT is not set, then since commit 0913ec336a6c0<br /> ("net: ks8851: Fix deadlock with the SPI chip variant") the deadlock<br /> can also be triggered without received packet in the RX FIFO. The<br /> pending softirqs will be processed on return from<br /> spin_unlock_bh(&amp;ks-&gt;statelock) in ks8851_irq(), which triggers the<br /> deadlock as well.<br /> <br /> Fix the problem by disabling BH around critical sections, including the<br /> IRQ handler, thus preventing the net_tx_action() softirq from triggering<br /> during these critical sections. The net_tx_action() softirq is triggered<br /> once BH are re-enabled and at the end of the IRQ handler, once all the<br /> other IRQ handler actions have been completed.<br /> <br /> __schedule from schedule_rtlock+0x1c/0x34<br /> schedule_rtlock from rtlock_slowlock_locked+0x548/0x904<br /> rtlock_slowlock_locked from rt_spin_lock+0x60/0x9c<br /> rt_spin_lock from ks8851_start_xmit_par+0x74/0x1a8<br /> ks8851_start_xmit_par from netdev_start_xmit+0x20/0x44<br /> netdev_start_xmit from dev_hard_start_xmit+0xd0/0x188<br /> dev_hard_start_xmit from sch_direct_xmit+0xb8/0x25c<br /> sch_direct_xmit from __qdisc_run+0x1f8/0x4ec<br /> __qdisc_run from qdisc_run+0x1c/0x28<br /> qdisc_run from net_tx_action+0x1f0/0x268<br /> net_tx_action from handle_softirqs+0x1a4/0x270<br /> handle_softirqs from __local_bh_enable_ip+0xcc/0xe0<br /> __local_bh_enable_ip from __alloc_skb+0xd8/0x128<br /> __alloc_skb from __netdev_alloc_skb+0x3c/0x19c<br /> __netdev_alloc_skb from ks8851_irq+0x388/0x4d4<br /> ks8851_irq from irq_thread_fn+0x24/0x64<br /> irq_thread_fn from irq_thread+0x178/0x28c<br /> irq_thread from kthread+0x12c/0x138<br /> kthread from ret_from_fork+0x14/0x28