Most recent entries from all

ALSA-2026:53330 — Important: kernel security, bug fix, and enhancement update

2026-10-03T10:57:32.654297+00:00

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

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

Security Fix(es):

* kernel: fsnotify: Fix ordering of iput() and watched_objects decrement (CVE-2024-53143) * kernel: shmem: fix recovery on rename failures (CVE-2025-71072) * kernel: futex: Fix UaF between futex_key_to_node_opt() and vma_replace_policy() (CVE-2026-23415) * kernel: drm/amd/display: Do not skip unrelated mode changes in DSC validation (CVE-2026-31488) * kernel: ipc: limit next_id allocation to the valid ID range (CVE-2026-52923) * kernel: mm/slab: do not limit zeroing to orig_size when only red zoning is enabled (CVE-2026-64368) * kernel: net: openvswitch: reject oversized nested action attrs (CVE-2026-64531)

Bug Fix(es) and Enhancement(s):

* Kernel oops after increasing max number of mac addresses of a mlx5 VF [almalinux-10.2.z] (JIRA:AlmaLinux-213035) * AlmaLinux10.0 - s390/pkey: Check length in PKEY_VERIFYPROTK ioctl [almalinux-10.2.z] (JIRA:AlmaLinux-222503) * AlmaLinux10.0 - s390/pkey: Check length in pkey_pckmo handler implementation [almalinux-10.2.z] (JIRA:AlmaLinux-222505)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

bdu:2026-11991

2026-10-03T10:57:32.654447+00:00

bdu:2026-11991

BELL-CVE-2025-71072

2026-10-03T10:57:32.654467+00:00

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

certfr-2026-avi-0166 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Elles permettent à un attaquant de provo…

2026-10-03T10:57:32.654487+00:00

certfr-2026-avi-0166

EUVD-2026-347536

2026-10-03T10:57:32.654503+00:00

EUVD-2026-347536

fkie_cve-2025-71072

2026-10-03T10:57:32.654514+00:00

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

shmem: fix recovery on rename failures

maple_tree insertions can fail if we are seriously short on memory; simple_offset_rename() does not recover well if it runs into that. The same goes for simple_offset_rename_exchange().

Moreover, shmem_whiteout() expects that if it succeeds, the caller will progress to d_move(), i.e. that shmem_rename2() won't fail past the successful call of shmem_whiteout().

Not hard to fix, fortunately - mtree_store() can't fail if the index we are trying to store into is already present in the tree as a singleton.

For simple_offset_rename_exchange() that's enough - we just need to be careful about the order of operations.

For simple_offset_rename() solution is to preinsert the target into the tree for new_dir; the rest can be done without any potentially failing operations.

That preinsertion has to be done in shmem_rename2() rather than in simple_offset_rename() itself - otherwise we'd need to deal with the possibility of failure after successful shmem_whiteout().

GHSA-2j2j-fmxq-39xm

2026-10-03T10:57:32.654547+00:00

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

shmem: fix recovery on rename failures

maple_tree insertions can fail if we are seriously short on memory; simple_offset_rename() does not recover well if it runs into that. The same goes for simple_offset_rename_exchange().

Moreover, shmem_whiteout() expects that if it succeeds, the caller will progress to d_move(), i.e. that shmem_rename2() won't fail past the successful call of shmem_whiteout().

Not hard to fix, fortunately - mtree_store() can't fail if the index we are trying to store into is already present in the tree as a singleton.

For simple_offset_rename_exchange() that's enough - we just need to be careful about the order of operations.

For simple_offset_rename() solution is to preinsert the target into the tree for new_dir; the rest can be done without any potentially failing operations.

That preinsertion has to be done in shmem_rename2() rather than in simple_offset_rename() itself - otherwise we'd need to deal with the possibility of failure after successful shmem_whiteout().

msrc_CVE-2025-71072 — shmem: fix recovery on rename failures

2026-10-03T10:57:32.654572+00:00

msrc_CVE-2025-71072

OESA-2026-1759 — kernel security update

2026-10-03T10:57:32.654588+00:00

Affected: openEuler:24.03-LTS: kernel

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

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

iommu/s390: Implement blocking domain

This fixes a crash when surprise hot-unplugging a PCI device. This crash happens because during hot-unplug __iommu_group_set_domain_nofail() attaching the default domain fails when the platform no longer recognizes the device as it has already been removed and we end up with a NULL domain pointer and UAF. This is exactly the case referred to in the second comment in __iommu_device_set_domain() and just as stated there if we can instead attach the blocking domain the UAF is prevented as this can handle the already removed device. Implement the blocking domain to use this handling. With this change, the crash is fixed but we still hit a warning attempting to change DMA ownership on a blocked device.(CVE-2024-53232)

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

iommu: Fix two issues in iommu_copy_struct_from_user()

In the review for iommu_copy_struct_to_user() helper, Matt pointed out that a NULL pointer should be rejected prior to dereferencing it: https://lore.kernel.org/all/(CVE-2025-37900)

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

smb: client: Avoid race in open_cached_dir with lease breaks

A pre-existing valid cfid returned from find_or_create_cached_dir might race with a lease break, meaning open_cached_dir doesn't consider it valid,…

RHSA-2026:53330 — Red Hat Security Advisory: kernel security, bug fix, and enhancement update

2026-10-03T10:57:32.655277+00:00

kernel: fsnotify: Fix ordering of iput() and watched_objects decrement kernel: shmem: fix recovery on rename failures kernel: futex: Fix UaF between futex_key_to_node_opt() and vma_replace_policy() kernel: drm/amd/display: Do not skip unrelated mode changes in DSC validation kernel: ipc: limit next_id allocation to the valid ID range kernel: mm/slab: do not limit zeroing to orig_size when only red zoning is enabled kernel: net: openvswitch: reject oversized nested action attrs

RLSA-2026:53330 — Important: kernel security, bug fix, and enhancement update

2026-10-03T10:57:32.655311+00:00

Affected: Rocky Linux:10: kernel

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

Security Fix(es):

* kernel: fsnotify: Fix ordering of iput() and watched_objects decrement (CVE-2024-53143)

* kernel: shmem: fix recovery on rename failures (CVE-2025-71072)

* kernel: futex: Fix UaF between futex_key_to_node_opt() and vma_replace_policy() (CVE-2026-23415)

* kernel: drm/amd/display: Do not skip unrelated mode changes in DSC validation (CVE-2026-31488)

* kernel: ipc: limit next_id allocation to the valid ID range (CVE-2026-52923)

* kernel: mm/slab: do not limit zeroing to orig_size when only red zoning is enabled (CVE-2026-64368)

* kernel: net: openvswitch: reject oversized nested action attrs (CVE-2026-64531)

Bug Fix(es) and Enhancement(s):

* Kernel oops after increasing max number of mac addresses of a mlx5 VF [rhel-10.2.z] (JIRA:Rocky Linux-213035)

* Rocky Linux10.0 - s390/pkey: Check length in PKEY_VERIFYPROTK ioctl [rhel-10.2.z] (JIRA:Rocky Linux-222503)

* Rocky Linux10.0 - s390/pkey: Check length in pkey_pckmo handler implementation [rhel-10.2.z] (JIRA:Rocky Linux-222505)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

UBUNTU-CVE-2025-71072

2026-10-03T10:57:32.655347+00:00

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:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 140 more

In the Linux kernel, the following vulnerability has been resolved: shmem: fix recovery on rename failures maple_tree insertions can fail if we are seriously short on memory; simple_offset_rename() does not recover well if it runs into that. The same goes for simple_offset_rename_exchange(). Moreover, shmem_whiteout() expects that if it succeeds, the caller will progress to d_move(), i.e. that shmem_rename2() won't fail past the successful call of shmem_whiteout(). Not hard to fix, fortunately - mtree_store() can't fail if the index we are trying to store into is already present in the tree as a singleton. For simple_offset_rename_exchange() that's enough - we just need to be careful about the order of operations. For simple_offset_rename() solution is to preinsert the target into the tree for new_dir; the rest can be done without any potentially failing operations. That preinsertion has to be done in shmem_rename2() rather than in simple_offset_rename() itself - otherwise we'd need to deal with the possibility of failure after successful shmem_whiteout().

WID-SEC-W-2026-0086 — Linux Kernel: Mehrere Schwachstellen

2026-10-03T10:57:32.655552+00:00

Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.