ALINUX4-SA-2026:0334
摘要
Package updates are available for Alibaba Cloud Linux 4 that fix the following vulnerabilities: CVE-2026-43499: In the Linux kernel, the following vulnerability has been resolved:rtmutex: Use waiter::task instead of current in remove_waiter()remove_waiter() is used by the slowlock paths, but it is also used forproxy-lock rollback in rt_mutex_start_proxy_lock() when invoked fromfutex_requeue().In the latter case waiter::task is not current, but remove_waiter()operates on current for the dequeue operation. That results in severalproblems: 1) the rbtree dequeue happens without waiter::task::pi_lock being held 2) the waiter task's pi_blocked_on state is not cleared, which leaves a dangling pointer primed for UAF around. 3) rt_mutex_adjust_prio_chain() operates on the wrong top priority waiter taskUse waiter::task instead of current in all related operations inremove_waiter() to cure those problems.[ tglx: Fixup rt_mutex_adjust_prio_chain(), add a comment and amend the changelog ] CVE-2026-43503: In the Linux kernel, the following vulnerability has been resolved:net: skbuff: propagate shared-frag marker through frag-transfer helpersTwo frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) failto propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags whenmoving frags from source to destination. __pskb_copy_fclone() defersthe rest of the shinfo metadata to skb_copy_header() after copyingfrag descriptors, but that helper only carries over gso_{size,segs,type} and never touches skb_shinfo()->flags; skb_shift() moves fragdescriptors directly and leaves flags untouched. As a result, thedestination skb keeps a reference to the same externally-owned orpage-cache-backed pages while reporting skb_has_shared_frag() asfalse.The mismatch is harmful in any in-place writer that usesskb_has_shared_frag() to decide whether shared pages must be detouredthrough skb_cow_data(). ESP input is one such writer (esp4.c,esp6.c), and a single nft 'dup to <local>' rule -- or any othernf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()'dskb in esp_input() with the marker stripped, letting an unprivilegeduser write into the page cache of a root-owned read-only file viaauthencesn-ESN stray writes.Set SKBFL_SHARED_FRAG on the destination whenever frag descriptorswere actually moved from the source. skb_copy() and skb_copy_expand()share skb_copy_header() too but linearize all paged data into freshlyallocated head storage and emerge with nr_frags == 0, soskb_has_shared_frag() returns false on its own; they need no change.The same omission exists in skb_gro_receive() and skb_gro_receive_list().The former moves the incoming skb's frag descriptors into theaccumulator's last sub-skb via two paths (a direct frag-move loop andthe head_frag + memcpy path); the latter chains the incoming skb wholeonto p's frag_list. Downstream skb_segment() reads onlyskb_shinfo(p)->flags, and skb_segment_list() reuses each sub-skb'sshinfo as the nskb -- both p and lp must carry the marker.The same omission also exists in tcp_clone_payload(), which builds anMTU probe skb by moving frag descriptors from skbs on sk_write_queueinto a freshly allocated nskb. The helper falls into the same familyand warrants the same fix for consistency; no TCP TX-side in-placewriter is currently known to reach a user page through this gap, buta future consumer depending on the marker would regress silently.The same omission exists in skb_segment(): the per-iteration flagmerge takes only head_skb's flag, and the inner switch that rebindsfrag_skb to list_skb on head_skb-frags exhaustion does not fold thenew frag_skb's flag into nskb. Fold frag_skb's flag at both sitesso segments drawing frags from frag_list members carry the marker. CVE-2026-46242: In the Linux kernel, the following vulnerability has been resolved:eventpoll: fix ep_remove struct eventpoll / struct file UAFep_remove() (via ep_remove_file()) cleared file->f_ep underfile->f_lock but then kept using @file inside the critical section(is_file_epoll(), hlist_del_rcu() through the head, spin_unlock).A concurrent __fput() taking the eventpoll_release() fastpath inthat window observed the transient NULL, skippedeventpoll_release_file() and ran to f_op->release / file_free().For the epoll-watches-epoll case, f_op->release isep_eventpoll_release() -> ep_clear_and_put() -> ep_free(), whichkfree()s the watched struct eventpoll. Its embedded ->refshlist_head is exactly where epi->fllink.pprev points, so thesubsequent hlist_del_rcu()'s "*pprev = next" scribbles into freedkmalloc-192 memory.In addition, struct file is SLAB_TYPESAFE_BY_RCU, so the slotbacking @file could be recycled by alloc_empty_file() --reinitializing f_lock and f_ep -- while ep_remove() is stillnominally inside that lock. The upshot is an attacker-controllablekmem_cache_free() against the wrong slab cache.Pin @file via epi_fget() at the top of ep_remove() and gate thecritical section on the pin succeeding. With the pin held @filecannot reach refcount zero, which holds __fput() off andtransitively keeps the watched struct eventpoll alive across thehlist_del_rcu() and the f_lock use, closing both UAFs.If the pin fails @file has already reached refcount zero and its__fput() is in flight. Because we bailed before clearing f_ep,that path takes the eventpoll_release() slow path intoeventpoll_release_file() and blocks on ep->mtx until the waiterside's ep_clear_and_put() drops it. The bailed epi's share ofep->refcount stays intact, so the trailing ep_refcount_dec_and_test()in ep_clear_and_put() cannot free the eventpoll out from undereventpoll_release_file(); the orphaned epi is then cleaned upthere.A successful pin also proves we are not racingeventpoll_release_file() on this epi, so drop the now-redundantre-check of epi->dying under f_lock. The cheap locklessREAD_ONCE(epi->dying) fast-path bailout stays. CVE-2026-46331: In the Linux kernel, the following vulnerability has been resolved:net/sched: fix pedit partial COW leading to page cache corruptiontcf_pedit_act() computes the COW range for skb_ensure_writable()once before the key loop using tcfp_off_max_hint, but the hint doesnot account for the runtime header offset added by typed keys. Thiscan leave part of the write region un-COW'd.Fix by moving skb_ensure_writable() inside the per-key loop wherethe actual write offset is known, and add overflow checking on theoffset arithmetic. For negative offsets (e.g. Ethernet header editsat ingress), use skb_cow() to COW the headroom instead. Guardoffset_valid() against INT_MIN, where negation is undefined. CVE-2026-53166: In the Linux kernel, the following vulnerability has been resolved: futex/requeue: Prevent NULL pointer dereference in remove_waiter() on self-deadlock When FUTEX_CMP_REQUEUE_PI requeues a non-top waiter that already owns the target PI futex, task_blocks_on_rt_mutex() returns -EDEADLK before setting waiter->task. The subsequent remove_waiter() in rt_mutex_start_proxy_lock() dereferences the NULL waiter->task, causing a kernel crash. Add a self-deadlock check for non-top waiters before calling rt_mutex_start_proxy_lock(), analogous to the top-waiter check in futex_lock_pi_atomic(). **Solution**: 请您尽快将升级到修复后的版本。修复命令如下： yum update --advisory ALINUX4-SA-2026:0334 **Affected Products**: Alinux 4
正文
Package updates are available for Alibaba Cloud Linux 4 that fix the following vulnerabilities: CVE-2026-43499: In the Linux kernel, the following vulnerability has been resolved:rtmutex: Use waiter::task instead of current in remove_waiter()remove_waiter() is used by the slowlock paths, but it is also used forproxy-lock rollback in rt_mutex_start_proxy_lock() when invoked fromfutex_requeue().In the latter case waiter::task is not current, but remove_waiter()operates on current for the dequeue operation. That results in severalproblems: 1) the rbtree dequeue happens without waiter::task::pi_lock being held 2) the waiter task's pi_blocked_on state is not cleared, which leaves a dangling pointer primed for UAF around. 3) rt_mutex_adjust_prio_chain() operates on the wrong top priority waiter taskUse waiter::task instead of current in all related operations inremove_waiter() to cure those problems.[ tglx: Fixup rt_mutex_adjust_prio_chain(), add a comment and amend the changelog ] CVE-2026-43503: In the Linux kernel, the following vulnerability has been resolved:net: skbuff: propagate shared-frag marker through frag-transfer helpersTwo frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) failto propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags whenmoving frags from source to destination. __pskb_copy_fclone() defersthe rest of the shinfo metadata to skb_copy_header() after copyingfrag descriptors, but that helper only carries over gso_{size,segs,type} and never touches skb_shinfo()->flags; skb_shift() moves fragdescriptors directly and leaves flags untouched. As a result, thedestination skb keeps a reference to the same externally-owned orpage-cache-backed pages while reporting skb_has_shared_frag() asfalse.The mismatch is harmful in any in-place writer that usesskb_has_shared_frag() to decide whether shared pages must be detouredthrough skb_cow_data(). ESP input is one such writer (esp4.c,esp6.c), and a single nft 'dup to <local>' rule -- or any othernf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()'dskb in esp_input() with the marker stripped, letting an unprivilegeduser write into the page cache of a root-owned read-only file viaauthencesn-ESN stray writes.Set SKBFL_SHARED_FRAG on the destination whenever frag descriptorswere actually moved from the source. skb_copy() and skb_copy_expand()share skb_copy_header() too but linearize all paged data into freshlyallocated head storage and emerge with nr_frags == 0, soskb_has_shared_frag() returns false on its own; they need no change.The same omission exists in skb_gro_receive() and skb_gro_receive_list().The former moves the incoming skb's frag descriptors into theaccumulator's last sub-skb via two paths (a direct frag-move loop andthe head_frag + memcpy path); the latter chains the incoming skb wholeonto p's frag_list. Downstream skb_segment() reads onlyskb_shinfo(p)->flags, and skb_segment_list() reuses each sub-skb'sshinfo as the nskb -- both p and lp must carry the marker.The same omission also exists in tcp_clone_payload(), which builds anMTU probe skb by moving frag descriptors from skbs on sk_write_queueinto a freshly allocated nskb. The helper falls into the same familyand warrants the same fix for consistency; no TCP TX-side in-placewriter is currently known to reach a user page through this gap, buta future consumer depending on the marker would regress silently.The same omission exists in skb_segment(): the per-iteration flagmerge takes only head_skb's flag, and the inner switch that rebindsfrag_skb to list_skb on head_skb-frags exhaustion does not fold thenew frag_skb's flag into nskb. Fold frag_skb's flag at both sitesso segments drawing frags from frag_list members carry the marker. CVE-2026-46242: In the Linux kernel, the following vulnerability has been resolved:eventpoll: fix ep_remove struct eventpoll / struct file UAFep_remove() (via ep_remove_file()) cleared file->f_ep underfile->f_lock but then kept using @file inside the critical section(is_file_epoll(), hlist_del_rcu() through the head, spin_unlock).A concurrent __fput() taking the eventpoll_release() fastpath inthat window observed the transient NULL, skippedeventpoll_release_file() and ran to f_op->release / file_free().For the epoll-watches-epoll case, f_op->release isep_eventpoll_release() -> ep_clear_and_put() -> ep_free(), whichkfree()s the watched struct eventpoll. Its embedded ->refshlist_head is exactly where epi->fllink.pprev points, so thesubsequent hlist_del_rcu()'s "*pprev = next" scribbles into freedkmalloc-192 memory.In addition, struct file is SLAB_TYPESAFE_BY_RCU, so the slotbacking @file could be recycled by alloc_empty_file() --reinitializing f_lock and f_ep -- while ep_remove() is stillnominally inside that lock. The upshot is an attacker-controllablekmem_cache_free() against the wrong slab cache.Pin @file via epi_fget() at the top of ep_remove() and gate thecritical section on the pin succeeding. With the pin held @filecannot reach refcount zero, which holds __fput() off andtransitively keeps the watched struct eventpoll alive across thehlist_del_rcu() and the f_lock use, closing both UAFs.If the pin fails @file has already reached refcount zero and its__fput() is in flight. Because we bailed before clearing f_ep,that path takes the eventpoll_release() slow path intoeventpoll_release_file() and blocks on ep->mtx until the waiterside's ep_clear_and_put() drops it. The bailed epi's share ofep->refcount stays intact, so the trailing ep_refcount_dec_and_test()in ep_clear_and_put() cannot free the eventpoll out from undereventpoll_release_file(); the orphaned epi is then cleaned upthere.A successful pin also proves we are not racingeventpoll_release_file() on this epi, so drop the now-redundantre-check of epi->dying under f_lock. The cheap locklessREAD_ONCE(epi->dying) fast-path bailout stays. CVE-2026-46331: In the Linux kernel, the following vulnerability has been resolved:net/sched: fix pedit partial COW leading to page cache corruptiontcf_pedit_act() computes the COW range for skb_ensure_writable()once before the key loop using tcfp_off_max_hint, but the hint doesnot account for the runtime header offset added by typed keys. Thiscan leave part of the write region un-COW'd.Fix by moving skb_ensure_writable() inside the per-key loop wherethe actual write offset is known, and add overflow checking on theoffset arithmetic. For negative offsets (e.g. Ethernet header editsat ingress), use skb_cow() to COW the headroom instead. Guardoffset_valid() against INT_MIN, where negation is undefined. CVE-2026-53166: In the Linux kernel, the following vulnerability has been resolved: futex/requeue: Prevent NULL pointer dereference in remove_waiter() on self-deadlock When FUTEX_CMP_REQUEUE_PI requeues a non-top waiter that already owns the target PI futex, task_blocks_on_rt_mutex() returns -EDEADLK before setting waiter->task. The subsequent remove_waiter() in rt_mutex_start_proxy_lock() dereferences the NULL waiter->task, causing a kernel crash. Add a self-deadlock check for non-top waiters before calling rt_mutex_start_proxy_lock(), analogous to the top-waiter check in futex_lock_pi_atomic().
标签
- cve:cve-2026-43499
- cve:cve-2026-43503
- cve:cve-2026-46242
- cve:cve-2026-46331
- cve:cve-2026-53166
- severity:important
- type:advisory
- vendor:alibaba
扩展字段
{
"advisory_id": "ALINUX4-SA-2026:0334",
"affected_products": [
"Alinux 4"
],
"cve_ids": [
"CVE-2026-43499",
"CVE-2026-43503",
"CVE-2026-46242",
"CVE-2026-46331",
"CVE-2026-53166"
],
"raw_pub_date": "Fri, 24 Jul 2026 17:46:42 +0800",
"solution": "请您尽快将升级到修复后的版本。修复命令如下：\nyum update --advisory ALINUX4-SA-2026:0334"
}