Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: authencesn - reject short ahash digests during instance creation<br /> <br /> authencesn requires either a zero authsize or an authsize of at least<br /> 4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of<br /> high-order sequence number data at the end of the authenticated data.<br /> <br /> While crypto_authenc_esn_setauthsize() already rejects explicit<br /> non-zero authsizes in the range 1..3, crypto_authenc_esn_create()<br /> still copied auth-&gt;digestsize into inst-&gt;alg.maxauthsize without<br /> validating it. The AEAD core then initialized the tfm&amp;#39;s default<br /> authsize from that value.<br /> <br /> As a result, selecting an ahash with digest size 1..3, such as<br /> cbcmac(cipher_null), exposed authencesn instances whose default<br /> authsize was invalid even though setauthsize() would have rejected the<br /> same value. AF_ALG could then trigger the ESN tail handling with a<br /> too-short tag and hit an out-of-bounds access.<br /> <br /> Reject authencesn instances whose ahash digest size is in the invalid<br /> non-zero range 1..3 so that no tfm can inherit an unsupported default<br /> authsize.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/slab: return NULL early from kmalloc_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, kmalloc_nolock() called from NMI context can re-enter the slab<br /> allocator and acquire n-&gt;list_lock that the interrupted context is<br /> already holding, corrupting slab state.<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 /> get_from_partial_node+0x120/0x4d0<br /> ___slab_alloc+0x8a/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 /> crypto: algif_aead - snapshot IV for async AEAD requests<br /> <br /> AF_ALG AEAD AIO requests currently use the socket-wide IV buffer during<br /> request processing. For async requests, later socket activity can<br /> update that shared state before the original request has fully<br /> completed, which can lead to inconsistent IV handling.<br /> <br /> Snapshot the IV into per-request storage when preparing the AEAD<br /> request, so in-flight operations no longer depend on mutable socket<br /> state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: avoid early lgr access in smc_clc_wait_msg<br /> <br /> A CLC decline can be received while the handshake is still in an early<br /> stage, before the connection has been associated with a link group.<br /> <br /> The decline handling in smc_clc_wait_msg() updates link-group level sync<br /> state for first-contact declines, but that state only exists after link<br /> group setup has completed. Guard the link-group update accordingly and<br /> keep the per-socket peer diagnosis handling unchanged.<br /> <br /> This preserves the existing sync_err handling for established link-group<br /> contexts and avoids touching link-group state before it is available.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/core: fix damon_call() vs kdamond_fn() exit race<br /> <br /> Patch series "mm/damon/core: fix damon_call()/damos_walk() vs kdmond exit<br /> race".<br /> <br /> damon_call() and damos_walk() can leak memory and/or deadlock when they<br /> race with kdamond terminations. Fix those.<br /> <br /> <br /> This patch (of 2);<br /> <br /> When kdamond_fn() main loop is finished, the function cancels all<br /> remaining damon_call() requests and unset the damon_ctx-&gt;kdamond so that<br /> API callers and API functions themselves can know the context is<br /> terminated. damon_call() adds the caller&amp;#39;s request to the queue first. <br /> After that, it shows if the kdamond of the damon_ctx is still running<br /> (damon_ctx-&gt;kdamond is set). Only if the kdamond is running, damon_call()<br /> starts waiting for the kdamond&amp;#39;s handling of the newly added request.<br /> <br /> The damon_call() requests registration and damon_ctx-&gt;kdamond unset are<br /> protected by different mutexes, though. Hence, damon_call() could race<br /> with damon_ctx-&gt;kdamond unset, and result in deadlocks.<br /> <br /> For example, let&amp;#39;s suppose kdamond successfully finished the damon_call()<br /> requests cancelling. Right after that, damon_call() is called for the<br /> context. It registers the new request, and shows the context is still<br /> running, because damon_ctx-&gt;kdamond unset is not yet done. Hence the<br /> damon_call() caller starts waiting for the handling of the request. <br /> However, the kdamond is already on the termination steps, so it never<br /> handles the new request. As a result, the damon_call() caller threads<br /> infinitely waits.<br /> <br /> Fix this by introducing another damon_ctx field, namely<br /> call_controls_obsolete. It is protected by the<br /> damon_ctx-&gt;call_controls_lock, which protects damon_call() requests<br /> registration. Initialize (unset) it in kdamond_fn() before letting<br /> damon_start() returns and set it just before the cancelling of remaining<br /> damon_call() requests is executed. damon_call() reads the obsolete field<br /> under the lock and avoids adding a new request.<br /> <br /> After this change, only requests that are guaranteed to be handled or<br /> cancelled are registered. Hence the after-registration DAMON context<br /> termination check is no longer needed. Remove it together.<br /> <br /> Note that the deadlock will not happen when damon_call() is called for<br /> repeat mode request. In tis case, damon_call() returns instead of waiting<br /> for the handling when the request registration succeeds and it shows the<br /> kdamond is running. However, if the request also has dealloc_on_cancel,<br /> the request memory would be leaked.<br /> <br /> The issue is found by sashiko [1].

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> EDAC/versalnet: Fix device_node leak in mc_probe()<br /> <br /> of_parse_phandle() returns a device_node reference that must be released with<br /> of_node_put(). The original code never freed r5_core_node on any exit path,<br /> causing a memory leak.<br /> <br /> Fix this by using the automatic cleanup attribute __free(device_node) which<br /> ensures of_node_put() is called when the variable goes out of scope.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qrtr: ns: Limit the maximum number of lookups<br /> <br /> Current code does no bound checking on the number of lookups a client can<br /> perform. Though the code restricts the lookups to local clients, there is<br /> still a possibility of a malicious local client sending a flood of<br /> NEW_LOOKUP messages over the same socket.<br /> <br /> Fix this issue by limiting the maximum number of lookups to 64 globally.<br /> Since the nameserver allows only atmost one local observer, this global<br /> lookup count will ensure that the lookups stay within the limit.<br /> <br /> Note that, limit of 64 is chosen based on the current platform<br /> requirements. If requirement changes in the future, this limit can be<br /> increased.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: atmel-aes - Fix 3-page memory leak in atmel_aes_buff_cleanup<br /> <br /> atmel_aes_buff_init() allocates 4 pages using __get_free_pages() with<br /> ATMEL_AES_BUFFER_ORDER, but atmel_aes_buff_cleanup() frees only the<br /> first page using free_page(), leaking the remaining 3 pages. Use<br /> free_pages() with ATMEL_AES_BUFFER_ORDER to fix the memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: stop parsing UAC2 rates at MAX_NR_RATES<br /> <br /> parse_uac2_sample_rate_range() caps the number of enumerated<br /> rates at MAX_NR_RATES, but it only breaks out of the current<br /> rate loop. A malformed UAC2 RANGE response with additional<br /> triplets continues parsing the remaining triplets and repeatedly<br /> prints "invalid uac2 rates" while probe still holds<br /> register_mutex.<br /> <br /> Stop the whole parse once the cap is reached and return the<br /> number of rates collected so far.