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: proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.al (CVE-2025-38653) * kernel: ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr (CVE-2025-68183) * kernel: nbd: defer config unlock in nbd_genl_connect (CVE-2025-68366) * kernel: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id (CVE-2025-68724) * kernel: iommu: disable SVA when CONFIG_X86 is set (CVE-2025-71089) * kernel: netfilter: nf_tables: release flowtable after rcu grace period on error (CVE-2026-23392) * kernel: netfilter: nf_conntrack_h323: check for zero length in DecodeQ931() (CVE-2026-23455) * kernel: Bluetooth: SCO: Fix use-after-free in sco_recv_frame() due to missing sock_hold (CVE-2026-31408) * kernel: net: sched: act_csum: validate nested VLAN headers (CVE-2026-31684) * kernel: netfilter: ip6t_eui64: reject invalid MAC header for all packets (CVE-2026-31685) * kernel: netfilter: nf_conntrack_helper: pass helper to expect cleanup (CVE-2026-43027) * kernel: Bluetooth: MGMT: validate LTK enc_size on load (CVE-2026-43020) * kernel: HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq (CVE-2026-43051) * kernel: smb: client: validate the whole DACL before rewriting it in cifsacl (CVE-2026-31709) * kernel: Bluetooth: SCO: fix race conditions in sco_sock_connect() (CVE-2026-43023) * kernel:…
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:
xfs: fix freemap adjustments when adding xattrs to leaf blocks
xfs/592 and xfs/794 both trip this assertion in the leaf block freemap adjustment code after ~20 minutes of running on my test VMs:
ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t) + xfs_attr3_leaf_hdr_size(leaf));
Upon enabling quite a lot more debugging code, I narrowed this down to fsstress trying to set a local extended attribute with namelen=3 and valuelen=71. This results in an entry size of 80 bytes.
At the start of xfs_attr3_leaf_add_work, the freemap looks like this:
i 0 base 448 size 0 rhs 448 count 46 i 1 base 388 size 132 rhs 448 count 46 i 2 base 2120 size 4 rhs 448 count 46 firstused = 520
where "rhs" is the first byte past the end of the leaf entry array. This is inconsistent -- the entries array ends at byte 448, but freemap[1] says there's free space starting at byte 388!
By the end of the function, the freemap is in worse shape:
i 0 base 456 size 0 rhs 456 count 47 i 1 base 388 size 52 rhs 456 count 47 i 2 base 2120 size 4 rhs 456 count 47 firstused = 440
Important note: 388 is not aligned with the entries array element size of 8 bytes.
Based on the incorrect freemap, the name area starts at byte 440, which is below the end of the entries array! That's why the assertion triggers and the filesystem shuts down.
How did we end up here? First, recall from the previous patch that the freema…
In the Linux kernel, the following vulnerability has been resolved:
xfs: fix freemap adjustments when adding xattrs to leaf blocks
xfs/592 and xfs/794 both trip this assertion in the leaf block freemap adjustment code after ~20 minutes of running on my test VMs:
ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t) + xfs_attr3_leaf_hdr_size(leaf));
Upon enabling quite a lot more debugging code, I narrowed this down to fsstress trying to set a local extended attribute with namelen=3 and valuelen=71. This results in an entry size of 80 bytes.
At the start of xfs_attr3_leaf_add_work, the freemap looks like this:
i 0 base 448 size 0 rhs 448 count 46 i 1 base 388 size 132 rhs 448 count 46 i 2 base 2120 size 4 rhs 448 count 46 firstused = 520
where "rhs" is the first byte past the end of the leaf entry array. This is inconsistent -- the entries array ends at byte 448, but freemap[1] says there's free space starting at byte 388!
By the end of the function, the freemap is in worse shape:
i 0 base 456 size 0 rhs 456 count 47 i 1 base 388 size 52 rhs 456 count 47 i 2 base 2120 size 4 rhs 456 count 47 firstused = 440
Important note: 388 is not aligned with the entries array element size of 8 bytes.
Based on the incorrect freemap, the name area starts at byte 440, which is below the end of the entries array! That's why the assertion triggers and the filesystem shuts down.
How did we end up here? First, recall from the previous patch that the freema…
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: Bluetooth: MGMT: Fix possible UAFs kernel: ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr kernel: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events kernel: libceph: make decode_pool() more resilient against corrupted osdmaps kernel: Linux kernel: Denial of service and memory corruption in RDMA umad kernel: Linux kernel: Use-after-free in traffic control (act_ct) may lead to denial of service or privilege escalation kernel: netfilter: nf_conntrack_h323: check for zero length in DecodeQ931() kernel: Bluetooth: SCO: Fix use-after-free in sco_recv_frame() due to missing sock_hold kernel: can: raw: fix ro->uniq use-after-free in raw_rcv() kernel: net: sched: act_csum: validate nested VLAN headers kernel: netfilter: ip6t_eui64: reject invalid MAC header for all packets kernel: smb: client: validate the whole DACL before rewriting it in cifsacl kernel: Bluetooth: MGMT: validate LTK enc_size on load kernel: netfilter: nf_conntrack_helper: pass helper to expect cleanup kernel: HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq kernel: xfs: fix freemap adjustments when adding xattrs to leaf blocks kernel: md/bitmap: fix GPF in write_page caused by resize race kernel: netfilter: xt_tcpmss: check remaining length before reading optlen kernel: smb: client: validate dacloffset before building DACL pointers
Affected: Rocky Linux:9: kernel
The kernel packages contain the Linux kernel, the core of any Linux operating system.
Security Fix(es):
* kernel: proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.al (CVE-2025-38653)
* kernel: ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr (CVE-2025-68183)
* kernel: nbd: defer config unlock in nbd_genl_connect (CVE-2025-68366)
* kernel: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id (CVE-2025-68724)
* kernel: iommu: disable SVA when CONFIG_X86 is set (CVE-2025-71089)
* kernel: netfilter: nf_tables: release flowtable after rcu grace period on error (CVE-2026-23392)
* kernel: netfilter: nf_conntrack_h323: check for zero length in DecodeQ931() (CVE-2026-23455)
* kernel: Bluetooth: SCO: Fix use-after-free in sco_recv_frame() due to missing sock_hold (CVE-2026-31408)
* kernel: net: sched: act_csum: validate nested VLAN headers (CVE-2026-31684)
* kernel: netfilter: ip6t_eui64: reject invalid MAC header for all packets (CVE-2026-31685)
* kernel: netfilter: nf_conntrack_helper: pass helper to expect cleanup (CVE-2026-43027)
* kernel: Bluetooth: MGMT: validate LTK enc_size on load (CVE-2026-43020)
* kernel: HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq (CVE-2026-43051)
* kernel: smb: client: validate the whole DACL before rewriting it in cifsacl (CVE-2026-31709)
* kernel: Bluetooth: SCO: fix race conditions in sco_sock_connect() (CVE-2026-43023)
* kernel: wifi: brcmfmac: vali…
Security update for the Linux Kernel
Affected: Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 232 more
In the Linux kernel, the following vulnerability has been resolved: xfs: fix freemap adjustments when adding xattrs to leaf blocks xfs/592 and xfs/794 both trip this assertion in the leaf block freemap adjustment code after ~20 minutes of running on my test VMs: ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t) + xfs_attr3_leaf_hdr_size(leaf)); Upon enabling quite a lot more debugging code, I narrowed this down to fsstress trying to set a local extended attribute with namelen=3 and valuelen=71. This results in an entry size of 80 bytes. At the start of xfs_attr3_leaf_add_work, the freemap looks like this: i 0 base 448 size 0 rhs 448 count 46 i 1 base 388 size 132 rhs 448 count 46 i 2 base 2120 size 4 rhs 448 count 46 firstused = 520 where "rhs" is the first byte past the end of the leaf entry array. This is inconsistent -- the entries array ends at byte 448, but freemap[1] says there's free space starting at byte 388! By the end of the function, the freemap is in worse shape: i 0 base 456 size 0 rhs 456 count 47 i 1 base 388 size 52 rhs 456 count 47 i 2 base 2120 size 4 rhs 456 count 47 firstused = 440 Important note: 388 is not aligned with the entries array element size of 8 bytes. Based on the incorrect freemap, the name area starts at byte 440, which is below the end of the entries array! That's why the assertion triggers and the filesystem shuts down. How did we end up here? First, recall from the previous patch that the freemap array in a…
Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht spezifizierte Angriffe durchzuführen, möglicherweise Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren oder offenzulegen oder einen Denial-of-Service-Zustand zu verursachen.