Vulnerabilidades

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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].

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: fix deferred split queue races during migration<br /> <br /> migrate_folio_move() records the deferred split queue state from src and<br /> replays it on dst. Replaying it after remove_migration_ptes(src, dst, 0)<br /> makes dst visible before it is requeued, so a concurrent rmap-removal path<br /> can mark dst partially mapped and trip the WARN in deferred_split_folio().<br /> <br /> Move the requeue before remove_migration_ptes() so dst is back on the<br /> deferred split queue before it becomes visible again.<br /> <br /> Because migration still holds dst locked at that point, teach<br /> deferred_split_scan() to requeue a folio when folio_trylock() fails. <br /> Otherwise a fully mapped underused folio can be dequeued by the shrinker<br /> and silently lost from split_queue.<br /> <br /> [ziy@nvidia.com: move the comment]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: xlnx: Only access buffer information if IPI is buffered<br /> <br /> In the receive callback check if message is NULL to prevent<br /> possibility of crash by NULL pointer dereferencing.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: Prevent potential null-ptr-deref in ceph_handle_auth_reply()<br /> <br /> If a message of type CEPH_MSG_AUTH_REPLY contains a zero value for both<br /> protocol and result, this is currently not treated as an error. In case<br /> of ac-&gt;negotiating == true and ac-&gt;protocol &gt; 0, this leads to setting<br /> ac-&gt;protocol = 0 and ac-&gt;ops = NULL. Thereafter, the check for<br /> ac-&gt;protocol != protocol returns false, and init_protocol() is not<br /> called. Subsequently, ac-&gt;ops-&gt;handle_reply() is called, which leads to<br /> a null pointer dereference, because ac-&gt;ops is still NULL.<br /> <br /> This patch changes the check for ac-&gt;protocol != protocol to<br /> !ac-&gt;protocol, as this also includes the case when the protocol was set<br /> to zero in the message. This causes the message to be treated as<br /> containing a bad auth protocol.