Affected: AlmaLinux:9: kernel, AlmaLinux:9: kernel-64k, AlmaLinux:9: kernel-64k-core, AlmaLinux:9: kernel-64k-debug, AlmaLinux:9: kernel-64k-debug-core, AlmaLinux:9: kernel-64k-debug-devel, AlmaLinux:9: kernel-64k-debug-devel-matched, AlmaLinux:9: kernel-64k-debug-modules, AlmaLinux:9: kernel-64k-debug-modules-core, AlmaLinux:9: kernel-64k-debug-modules-extra and 64 more

The kernel packages contain the Linux kernel, the core of any Linux operating system.

Security Fix(es):

* kernel: fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath (CVE-2026-43112) * kernel: net: mana: Fix double destroy_workqueue on service rescan PCI path (CVE-2026-43276) * kernel: Linux kernel: Use-After-Free in net/gro due to improper handling of zerocopy skbs (CVE-2026-46323) * kernel: xfrm: defensively unhash xfrm_state lists in __xfrm_state_delete (CVE-2026-46116) * kernel: sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL (CVE-2026-46227) * kernel: drm/gem: Fix inconsistent plane dimension calculation in drm_gem_fb_init_with_funcs() (CVE-2026-46209) * kernel: smb/client: fix out-of-bounds read in smb2_compound_op() (CVE-2026-46155) * kernel: netfilter: nft_inner: Fix IPv6 inner_thoff desync (CVE-2026-46244) * kernel: procfs: fix missing RCU protection when reading real_parent in do_task_stat() (CVE-2026-46259) * kernel: Arm Processors: Privilege escalation or information disclosure via writes to higher exception level resources (CVE-2025-10263) * kernel: KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry (CVE-2026-46316)

Bug Fix(es) and Enhancement(s):

* WARNING at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:1585 r535_gsp_fini+0x2fb/0x310 [nouveau] [almalinux-9.8.z] (JIRA:AlmaLinux-160966)

For more details about the security issue(s), including the impact, a…

Affected: Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts

Important: kernel security, bug fix, and enhancement update

In the Linux kernel, the following vulnerability has been resolved:

sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL

The SCTP_SENDALL path in sctp_sendmsg() iterates ep->asocs with list_for_each_entry_safe(), which caches the next entry in @tmp before the loop body runs. The body calls sctp_sendmsg_to_asoc(), which may drop the socket lock inside sctp_wait_for_sndbuf().

While the lock is dropped, another thread can SCTP_SOCKOPT_PEELOFF the association cached in @tmp, migrating it to a new endpoint via sctp_sock_migrate() (list_del_init() + list_add_tail() to newep->asocs), and optionally close the new socket which frees the association via kfree_rcu(). The cached @tmp can also be freed by a network ABORT for that association, processed in softirq while the lock is dropped.

sctp_wait_for_sndbuf() revalidates @asoc (the current entry) on re-lock via the "sk != asoc->base.sk" and "asoc->base.dead" checks, but nothing revalidates @tmp. After a successful return, the iterator advances to the stale @tmp, yielding either a use-after-free (if the peeled socket was closed) or a list-walk onto the new endpoint's list head (type confusion of &newep->asocs as a struct sctp_association *).

Both are reachable from CapEff=0; the type-confusion path gives controlled indirect call via the outqueue.sched->init_sid pointer.

Fix by re-deriving @tmp from @asoc after sctp_sendmsg_to_asoc() returns. @asoc is known to still be on ep->asocs at that point: the only…

In the Linux kernel, the following vulnerability has been resolved:

sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL

The SCTP_SENDALL path in sctp_sendmsg() iterates ep->asocs with list_for_each_entry_safe(), which caches the next entry in @tmp before the loop body runs. The body calls sctp_sendmsg_to_asoc(), which may drop the socket lock inside sctp_wait_for_sndbuf().

While the lock is dropped, another thread can SCTP_SOCKOPT_PEELOFF the association cached in @tmp, migrating it to a new endpoint via sctp_sock_migrate() (list_del_init() + list_add_tail() to newep->asocs), and optionally close the new socket which frees the association via kfree_rcu(). The cached @tmp can also be freed by a network ABORT for that association, processed in softirq while the lock is dropped.

sctp_wait_for_sndbuf() revalidates @asoc (the current entry) on re-lock via the "sk != asoc->base.sk" and "asoc->base.dead" checks, but nothing revalidates @tmp. After a successful return, the iterator advances to the stale @tmp, yielding either a use-after-free (if the peeled socket was closed) or a list-walk onto the new endpoint's list head (type confusion of &newep->asocs as a struct sctp_association *).

Both are reachable from CapEff=0; the type-confusion path gives controlled indirect call via the outqueue.sched->init_sid pointer.

Fix by re-deriving @tmp from @asoc after sctp_sendmsg_to_asoc() returns. @asoc is known to still be on ep->asocs at that point: the only…

Affected: openEuler:20.03-LTS-SP4: kernel

The Linux Kernel, the operating system core itself. Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

bcache: fix NULL pointer in cache_set_flush()

1. LINE#1794 - LINE#1887 is some codes about function of bch_cache_set_alloc(). 2. LINE#2078 - LINE#2142 is some codes about function of register_cache_set(). 3. register_cache_set() will call bch_cache_set_alloc() in LINE#2098.

1794 struct cache_set *bch_cache_set_alloc(struct cache_sb *sb) 1795 { ... 1860 if (!(c->devices = kcalloc(c->nr_uuids, sizeof(void *), GFP_KERNEL)) || 1861 mempool_init_slab_pool(&c->search, 32, bch_search_cache) || 1862 mempool_init_kmalloc_pool(&c->bio_meta, 2, 1863 sizeof(struct bbio) + sizeof(struct bio_vec) * 1864 bucket_pages(c)) || 1865 mempool_init_kmalloc_pool(&c->fill_iter, 1, iter_size) || 1866 bioset_init(&c->bio_split, 4, offsetof(struct bbio, bio), 1867 BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER) || 1868 !(c->uuids = alloc_bucket_pages(GFP_KERNEL, c)) || 1869 !(c->moving_gc_wq = alloc_workqueue("bcache_gc", 1870 WQ_MEM_RECLAIM, 0)) || 1871 bch_journal_alloc(c) || 1872 bch_btree_cache_alloc(c) || 1873 bch_open_buckets_alloc(c) || 1874…

kernel: ipv6: use RCU in ip6_xmit() kernel: ipv6: use RCU in ip6_output() kernel: net: use dst_dev_rcu() in sk_setup_caps() kernel: nbd: defer config unlock in nbd_genl_connect kernel: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id kernel: iommu: disable SVA when CONFIG_X86 is set kernel: libceph: make decode_pool() more resilient against corrupted osdmaps kernel: libceph: prevent potential out-of-bounds reads in handle_auth_done() kernel: libceph: replace overzealous BUG_ON in osdmap_apply_incremental() kernel: scsi: target: iscsi: Fix use-after-free in iscsit_dec_conn_usage_count() kernel: netfilter: nf_tables: release flowtable after rcu grace period on error kernel: netfilter: nf_conntrack_h323: check for zero length in DecodeQ931() kernel: netfilter: ip6t_eui64: reject invalid MAC header for all packets kernel: wifi: brcmfmac: validate bsscfg indices in IF events kernel: netfilter: ctnetlink: ensure safe access to master conntrack kernel: xfs: fix freemap adjustments when adding xattrs to leaf blocks kernel: netfilter: xt_tcpmss: check remaining length before reading optlen kernel: mm/page_alloc: clear page->private in free_pages_prepare() kernel: wifi: mac80211: remove station if connection prep fails kernel: sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL kernel: Linux kernel: smb: client: reject userspace cifs.spnego descriptions

Affected: Rocky Linux:9: kernel

The kernel packages contain the Linux kernel, the core of any Linux operating system.

Security Fix(es):

* kernel: fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath (CVE-2026-43112)

* kernel: net: mana: Fix double destroy_workqueue on service rescan PCI path (CVE-2026-43276)

* kernel: Linux kernel: Use-After-Free in net/gro due to improper handling of zerocopy skbs (CVE-2026-46323)

* kernel: xfrm: defensively unhash xfrm_state lists in __xfrm_state_delete (CVE-2026-46116)

* kernel: sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL (CVE-2026-46227)

* kernel: drm/gem: Fix inconsistent plane dimension calculation in drm_gem_fb_init_with_funcs() (CVE-2026-46209)

* kernel: smb/client: fix out-of-bounds read in smb2_compound_op() (CVE-2026-46155)

* kernel: netfilter: nft_inner: Fix IPv6 inner_thoff desync (CVE-2026-46244)

* kernel: procfs: fix missing RCU protection when reading real_parent in do_task_stat() (CVE-2026-46259)

* kernel: Arm Processors: Privilege escalation or information disclosure via writes to higher exception level resources (CVE-2025-10263)

* kernel: KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry (CVE-2026-46316)

Bug Fix(es) and Enhancement(s):

* WARNING at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:1585 r535_gsp_fini+0x2fb/0x310 [nouveau] [rhel-9.8.z] (JIRA:Rocky Linux-160966)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgme…

Security update for the Linux Kernel

Affected: Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 226 more

In the Linux kernel, the following vulnerability has been resolved: sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL The SCTP_SENDALL path in sctp_sendmsg() iterates ep->asocs with list_for_each_entry_safe(), which caches the next entry in @tmp before the loop body runs. The body calls sctp_sendmsg_to_asoc(), which may drop the socket lock inside sctp_wait_for_sndbuf(). While the lock is dropped, another thread can SCTP_SOCKOPT_PEELOFF the association cached in @tmp, migrating it to a new endpoint via sctp_sock_migrate() (list_del_init() + list_add_tail() to newep->asocs), and optionally close the new socket which frees the association via kfree_rcu(). The cached @tmp can also be freed by a network ABORT for that association, processed in softirq while the lock is dropped. sctp_wait_for_sndbuf() revalidates @asoc (the current entry) on re-lock via the "sk != asoc->base.sk" and "asoc->base.dead" checks, but nothing revalidates @tmp. After a successful return, the iterator advances to the stale @tmp, yielding either a use-after-free (if the peeled socket was closed) or a list-walk onto the new endpoint's list head (type confusion of &newep->asocs as a struct sctp_association *). Both are reachable from CapEff=0; the type-confusion path gives controlled indirect call via the outqueue.sched->init_sid pointer. Fix by re-deriving @tmp from @asoc after sctp_sendmsg_to_asoc() returns. @asoc is known to still be on ep->asocs at that point: the only caller…

Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere nicht näher spezifizierte Auswirkungen zu erzielen.