Affected: AlmaLinux:8: bpftool, AlmaLinux:8: kernel, AlmaLinux:8: kernel-abi-stablelists, AlmaLinux:8: kernel-core, AlmaLinux:8: kernel-cross-headers, AlmaLinux:8: kernel-debug, AlmaLinux:8: kernel-debug-core, AlmaLinux:8: kernel-debug-devel, AlmaLinux:8: kernel-debug-modules, AlmaLinux:8: kernel-debug-modules-extra and 15 more

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

Security Fix(es):

* kernel: crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg (CVE-2025-39964) * kernel: Linux kernel Bluetooth: Denial of Service via race condition in hidp_session_thread (CVE-2023-54120) * kernel: Bluetooth: L2CAP: Fix potential user-after-free (CVE-2023-54214) * kernel: Bluetooth: btusb: revert use of devm_kzalloc in btusb (CVE-2025-71082) * kernel: Bluetooth: SMP: force responder MITM requirements before building the pairing response (CVE-2026-43334) * kernel: iommu/vt-d: Clear Present bit before tearing down PASID entry (CVE-2026-45894) * kernel: RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv (CVE-2026-46043) * kernel: RDMA/rxe: Reject unknown opcodes before ICRC processing (CVE-2026-46133) * kernel: Bluetooth: serialize accept_q access (CVE-2026-52918) * kernel: dm cache policy smq: fix missing locks in invalidating cache blocks (CVE-2026-53062) * kernel: iommu/amd: Fix clone_alias() to use the original device's devid (CVE-2026-53053) * kernel: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() (CVE-2026-53256) * kernel: Bluetooth: RFCOMM: validate skb length in MCC handlers (CVE-2026-53254) * kernel: keys: Pin request_key_auth payload in instantiate paths (CVE-2026-63823) * kernel: Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp (CVE-2026-63975) * kernel: Bluetooth: HIDP: fi…

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

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

iommu/vt-d: Clear Present bit before tearing down PASID entry

The Intel VT-d Scalable Mode PASID table entry consists of 512 bits (64 bytes). When tearing down an entry, the current implementation zeros the entire 64-byte structure immediately using multiple 64-bit writes.

Since the IOMMU hardware may fetch these 64 bytes using multiple internal transactions (e.g., four 128-bit bursts), updating or zeroing the entire entry while it is active (P=1) risks a "torn" read. If a hardware fetch occurs simultaneously with the CPU zeroing the entry, the hardware could observe an inconsistent state, leading to unpredictable behavior or spurious faults.

Follow the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake:

1. Clear only the 'Present' (P) bit of the PASID entry. 2. Use a dma_wmb() to ensure the cleared bit is visible to hardware before proceeding. 3. Execute the required invalidation sequence (PASID cache, IOTLB, and Device-TLB flush) to ensure the hardware has released all cached references. 4. Only after the flushes are complete, zero out the remaining fields of the PASID entry.

Also, add a dma_wmb() in pasid_set_present() to ensure that all other fields of the PASID entry are visible to the hardware before the Present bit is set.

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

iommu/vt-d: Clear Present bit before tearing down PASID entry

The Intel VT-d Scalable Mode PASID table entry consists of 512 bits (64 bytes). When tearing down an entry, the current implementation zeros the entire 64-byte structure immediately using multiple 64-bit writes.

Since the IOMMU hardware may fetch these 64 bytes using multiple internal transactions (e.g., four 128-bit bursts), updating or zeroing the entire entry while it is active (P=1) risks a "torn" read. If a hardware fetch occurs simultaneously with the CPU zeroing the entry, the hardware could observe an inconsistent state, leading to unpredictable behavior or spurious faults.

Follow the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake:

1. Clear only the 'Present' (P) bit of the PASID entry. 2. Use a dma_wmb() to ensure the cleared bit is visible to hardware before proceeding. 3. Execute the required invalidation sequence (PASID cache, IOTLB, and Device-TLB flush) to ensure the hardware has released all cached references. 4. Only after the flushes are complete, zero out the remaining fields of the PASID entry.

Also, add a dma_wmb() in pasid_set_present() to ensure that all other fields of the PASID entry are visible to the hardware before the Present bit is set.

Affected: openEuler:22.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:

btrfs: qgroup: fix race between quota disable and quota rescan ioctl

There's a race between a task disabling quotas and another running the rescan ioctl that can result in a use-after-free of qgroup records from the fs_info->qgroup_tree rbtree.

This happens as follows:

1) Task A enters btrfs_ioctl_quota_rescan() -> btrfs_qgroup_rescan();

2) Task B enters btrfs_quota_disable() and calls btrfs_qgroup_wait_for_completion(), which does nothing because at that point fs_info->qgroup_rescan_running is false (it wasn't set yet by task A);

3) Task B calls btrfs_free_qgroup_config() which starts freeing qgroups from fs_info->qgroup_tree without taking the lock fs_info->qgroup_lock;

4) Task A enters qgroup_rescan_zero_tracking() which starts iterating the fs_info->qgroup_tree tree while holding fs_info->qgroup_lock, but task B is freeing qgroup records from that tree without holding the lock, resulting in a use-after-free.

Fix this by taking fs_info->qgroup_lock at btrfs_free_qgroup_config(). Also at btrfs_qgroup_rescan() don't start the rescan worker if quotas were already disabled.(CVE-2025-39759)

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

wifi: wilc1000: avoid buffer overflow in WID string configuration

Fix the following copy overflow warning identi…

Security update for the Linux Kernel

kernel: Linux kernel Bluetooth: Denial of Service via race condition in hidp_session_thread kernel: Bluetooth: L2CAP: Fix potential user-after-free kernel: crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg kernel: Bluetooth: btusb: revert use of devm_kzalloc in btusb kernel: Bluetooth: SMP: force responder MITM requirements before building the pairing response kernel: iommu/vt-d: Clear Present bit before tearing down PASID entry kernel: RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv kernel: RDMA/rxe: Reject unknown opcodes before ICRC processing kernel: Bluetooth: serialize accept_q access kernel: iommu/amd: Fix clone_alias() to use the original device's devid kernel: dm cache policy smq: fix missing locks in invalidating cache blocks kernel: Bluetooth: RFCOMM: validate skb length in MCC handlers kernel: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() kernel: keys: Pin request_key_auth payload in instantiate paths kernel: Bluetooth: HIDP: fix missing length checks in hidp_input_report() kernel: Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp kernel: nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path kernel: RDMA/rxe: Fix a use-after-free problem in rxe_mmap kernel: Linux kernel Bluetooth RFCOMM: Denial of Service via use-after-free in set_termios kernel: net/mlx5: Fix MCIA register buffer overflow on 32 dword reads

Affected: Rocky Linux:8: kernel

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

Security Fix(es):

* kernel: crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg (CVE-2025-39964)

* kernel: Linux kernel Bluetooth: Denial of Service via race condition in hidp_session_thread (CVE-2023-54120)

* kernel: Bluetooth: L2CAP: Fix potential user-after-free (CVE-2023-54214)

* kernel: Bluetooth: btusb: revert use of devm_kzalloc in btusb (CVE-2025-71082)

* kernel: Bluetooth: SMP: force responder MITM requirements before building the pairing response (CVE-2026-43334)

* kernel: iommu/vt-d: Clear Present bit before tearing down PASID entry (CVE-2026-45894)

* kernel: RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv (CVE-2026-46043)

* kernel: RDMA/rxe: Reject unknown opcodes before ICRC processing (CVE-2026-46133)

* kernel: Bluetooth: serialize accept_q access (CVE-2026-52918)

* kernel: dm cache policy smq: fix missing locks in invalidating cache blocks (CVE-2026-53062)

* kernel: iommu/amd: Fix clone_alias() to use the original device's devid (CVE-2026-53053)

* kernel: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() (CVE-2026-53256)

* kernel: Bluetooth: RFCOMM: validate skb length in MCC handlers (CVE-2026-53254)

* kernel: keys: Pin request_key_auth payload in instantiate paths (CVE-2026-63823)

* kernel: Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp (CVE-2026-63975)

* kernel: Bluetooth: HIDP: fix missing length chec…

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 206 more

In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Clear Present bit before tearing down PASID entry The Intel VT-d Scalable Mode PASID table entry consists of 512 bits (64 bytes). When tearing down an entry, the current implementation zeros the entire 64-byte structure immediately using multiple 64-bit writes. Since the IOMMU hardware may fetch these 64 bytes using multiple internal transactions (e.g., four 128-bit bursts), updating or zeroing the entire entry while it is active (P=1) risks a "torn" read. If a hardware fetch occurs simultaneously with the CPU zeroing the entry, the hardware could observe an inconsistent state, leading to unpredictable behavior or spurious faults. Follow the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake: 1. Clear only the 'Present' (P) bit of the PASID entry. 2. Use a dma_wmb() to ensure the cleared bit is visible to hardware before proceeding. 3. Execute the required invalidation sequence (PASID cache, IOTLB, and Device-TLB flush) to ensure the hardware has released all cached references. 4. Only after the flushes are complete, zero out the remaining fields of the PASID entry. Also, add a dma_wmb() in pasid_set_present() to ensure that all other fields of the PASID entry are visible to the hardware before the Present bit is set.

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.