CVE-2026-43048

In the Linux kernel, the following vulnerability has been resolved: HID: core: Mitigate potential OOB by removing bogus memset() The memset() in hid_report_raw_event() has the good intention of clearing out bogus data by zeroing the area from the end of the incoming data string to the assumed end of the buffer. However, as we have previously seen, doing so can easily result in OOB reads and writes in the subsequent thread of execution. The current suggestion from one of the HID maintainers is to remove the memset() and simply return if the incoming event buffer size is not large enough to fill the associated report. Suggested-by Benjamin Tissoires [email protected] [bentiss: changed the return value]

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

driver core: platform: use generic driver_override infrastructure

When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF.

Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally.

Note that calling match() from __driver_attach() without the device lock held is intentional. 1

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

crypto: ccp: Don't attempt to copy PDH cert to userspace if PSP command failed

When retrieving the PDH cert, don't attempt to copy the blobs to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes firmware requires will overflow the kernel-allocated buffer and leak data to userspace.

BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff8885c4ab8aa0 by task syz.0.186/21033

CPU: 51 UID: 0 PID: 21033 Comm: syz.0.186 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.84.12-0 11/17/2025 Call Trace: <TASK> dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pdh_export+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c:2347 sev_ioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c:2568 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK>

WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.(CVE-2026-31698)

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

crypto: ccp: Don't attempt to copy CSR to userspace if PSP command failed

When retrieving the PEK CSR, don't attempt to copy the blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes firmware requires will overflow the kernel-allocated buffer and leak data to userspace.

BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff898144612e20 by task syz.9.219/21405

CPU: 14 UID: 0 PID: 21405 Comm: syz.9.219 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc.…

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

smb: client: fix use-after-free in crypt_message when using async crypto

The CVE-2024-50047 fix removed asynchronous crypto handling from crypt_message(), assuming all crypto operations are synchronous. However, when hardware crypto accelerators are used, this can cause use-after-free crashes:

crypt_message() // Allocate the creq buffer containing the req creq = smb2_get_aead_req(..., &req);

// Async encryption returns -EINPROGRESS immediately
rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);

// Free creq while async operation is still in progress
kvfree_sensitive(creq, ...);

Hardware crypto modules often implement async AEAD operations for performance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS, the operation completes asynchronously. Without crypto_wait_req(), the function immediately frees the request buffer, leading to crashes when the driver later accesses the freed memory.

This results in a use-after-free condition when the hardware crypto driver later accesses the freed request structure, leading to kernel crashes with NULL pointer dereferences.

The issue occurs because crypto_alloc_aead() with mask=0 doesn't guarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in the mask, async implementations can be selected.

Fix by restoring the async crypto handling:

• DECLARE_CRYPTO_WAIT(wait) for completion tracking
• aead_request_set_callback() for async completion notification
• crypto_wait_req() to wait for operation completion

This ensures the request buffer isn't freed until the crypto operation completes, whether synchronous or asynchronous, while preserving the CVE-2024-50047 fix.(CVE-2025-38488)

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

scsi: lpfc: Fix buffer free/clear order in deferred receive path

Fix a use-after-free window by correcting the buffer release sequence in the deferred receive path. The code freed the RQ buffer first and only then cleared the context pointer under the lock. Concurrent paths (e.g., ABTS and the repost path) also inspect and release the same pointer under the lock, so the old order could lead to double-free/UAF.

Note that the repost path already uses the correct pattern: detach the pointer under the lock, then free it after dropping the lock. The deferred path should do the same.(CVE-2025-39841)

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

nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()

nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur:

[ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI:…

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MMWe currently assume that there is at least one VMA in a MM, which isn ttrue.So we might end up having find_vma() return NULL, to then de-referenceNULL. So properly handle find_vma() returning NULL.This fixes the report:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024RIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline]RIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194Code: ...RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8FS: 00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: <TASK> kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709 __do_sys_migrate_pages mm/mempolicy.c:1727 [inline] __se_sys_migrate_pages mm/mempolicy.c:1723 [inline] __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/[email protected]: add unlikely()

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

PCI/MSI: Handle lack of irqdomain gracefully

Alexandre observed a warning emitted from pci_msi_setup_msi_irqs() on a RISCV platform which does not provide PCI/MSI support:

WARNING: CPU: 1 PID: 1 at drivers/pci/msi/msi.h:121 pci_msi_setup_msi_irqs+0x2c/0x32 __pci_enable_msix_range+0x30c/0x596 pci_msi_setup_msi_irqs+0x2c/0x32 pci_alloc_irq_vectors_affinity+0xb8/0xe2

RISCV uses hierarchical interrupt domains and correctly does not implement the legacy fallback. The warning triggers from the legacy fallback stub.

That warning is bogus as the PCI/MSI layer knows whether a PCI/MSI parent domain is associated with the device or not. There is a check for MSI-X, which has a legacy assumption. But that legacy fallback assumption is only valid when legacy support is enabled, but otherwise the check should simply return -ENOTSUPP.

Loongarch tripped over the same problem and blindly enabled legacy support without implementing the legacy fallbacks. There are weak implementations which return an error, so the problem was papered over.

Correct pci_msi_domain_supports() to evaluate the legacy mode and add the missing supported check into the MSI enable path to complete it.(CVE-2024-56760)

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

NFS: fix nfs_release_folio() to not deadlock via kcompactd writeback

Add PF_KCOMPACTD flag and current_is_kcompactd() helper to check for it so nfs_release_folio() can skip calling nfs_wb_folio() from kcompactd.

Otherwise NFS can deadlock waiting for kcompactd enduced writeback which recurses back to NFS (which triggers writeback to NFSD via NFS loopback mount on the same host, NFSD blocks waiting for XFS's call to __filemap_get_folio):

6070.550357] INFO: task kcompactd0:58 blocked for more than 4435 seconds.

{--- [58] "kcompactd0" [<0>]…

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MMWe currently assume that there is at least one VMA in a MM, which isn ttrue.So we might end up having find_vma() return NULL, to then de-referenceNULL. So properly handle find_vma() returning NULL.This fixes the report:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024RIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline]RIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194Code: ...RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8FS: 00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: <TASK> kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709 __do_sys_migrate_pages mm/mempolicy.c:1727 [inline] __se_sys_migrate_pages mm/mempolicy.c:1723 [inline] __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/[email protected]: add unlikely()

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

PCI/MSI: Handle lack of irqdomain gracefully

Alexandre observed a warning emitted from pci_msi_setup_msi_irqs() on a RISCV platform which does not provide PCI/MSI support:

WARNING: CPU: 1 PID: 1 at drivers/pci/msi/msi.h:121 pci_msi_setup_msi_irqs+0x2c/0x32 __pci_enable_msix_range+0x30c/0x596 pci_msi_setup_msi_irqs+0x2c/0x32 pci_alloc_irq_vectors_affinity+0xb8/0xe2

RISCV uses hierarchical interrupt domains and correctly does not implement the legacy fallback. The warning triggers from the legacy fallback stub.

That warning is bogus as the PCI/MSI layer knows whether a PCI/MSI parent domain is associated with the device or not. There is a check for MSI-X, which has a legacy assumption. But that legacy fallback assumption is only valid when legacy support is enabled, but otherwise the check should simply return -ENOTSUPP.

Loongarch tripped over the same problem and blindly enabled legacy support without implementing the legacy fallbacks. There are weak implementations which return an error, so the problem was papered over.

Correct pci_msi_domain_supports() to evaluate the legacy mode and add the missing supported check into the MSI enable path to complete it.(CVE-2024-56760)

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

NFS: fix nfs_release_folio() to not deadlock via kcompactd writeback

Add PF_KCOMPACTD flag and current_is_kcompactd() helper to check for it so nfs_release_folio() can skip calling nfs_wb_folio() from kcompactd.

Otherwise NFS can deadlock waiting for kcompactd enduced writeback which recurses back to NFS (which triggers writeback to NFSD via NFS loopback mount on the same host, NFSD blocks waiting for XFS's call to __filemap_get_folio):

6070.550357] INFO: task kcompactd0:58 blocked for more than 4435 seconds.

{--- [58] "kcompactd0" [<0>]…

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access

l2cap_information_rsp() checks that cmd_len covers the fixed l2cap_info_rsp header (type + result, 4 bytes) but then reads rsp->data without verifying that the payload is present:

• L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp->data), which reads 4 bytes past the header (needs cmd_len >= 8).

• L2CAP_IT_FIXED_CHAN reads rsp->data[0], 1 byte past the header (needs cmd_len >= 5).

A truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an out-of-bounds read of adjacent skb data.

Guard each data access with the required payload length check. If the payload is too short, skip the read and let the state machine complete with safe defaults (feat_mask and remote_fixed_chan remain zero from kzalloc), so the info timer cleanup and l2cap_conn_start() still run and the connection is not stalled.(CVE-2026-31393)

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

ext4: reject mount if bigalloc with s_first_data_block != 0

bigalloc with s_first_data_block != 0 is not supported, reject mounting it.(CVE-2026-31447)

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

HID: multitouch: Check to ensure report responses match the request

It is possible for a malicious (or clumsy) device to respond to a specific report's feature request using a completely different report ID. This can cause confusion in the HID core resulting in nasty side-effects such as OOB writes.

Add a check to ensure that the report ID in the response, matches the one that was requested. If it doesn't, omit reporting the raw event and return early.(CVE-2026-43047)

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

HID: core: Mitigate potential OOB by removing bogus memset()

The memset() in hid_report_raw_event() has the good intention of clearing out bogus data by zeroing the area from the end of the incoming data string to the assumed end of the buffer. However, as we have previously seen, doing so can easily result in OOB reads and writes in the subsequent thread of execution.

The current suggestion from one of the HID maintainers is to remove the memset() and simply return if the incoming event buffer size is not large enough to fill the associated report.

Suggested-by Benjamin Tissoires <(CVE-2026-43048)

In the Linux kernel, there is a potential out-of-bounds access vulnerability in the ceph_handle_auth_reply() function of the libceph component. When processing messages of type CEPH_MSG_AUTH_REPLY, the value of the payload_len field is stored in a variable of type int. A value greater than INT_MAX leads to integer overflow and is interpreted as a negative value, which causes the pointer address to be decremented and subsequently accessed because ceph_decode_need() only checks that the memory access does not exceed the end address of the allocation. The vulnerability is fixed by changing the data type of payload_len to u32 and introducing additional sanity checks.(CVE-2026-43407)

Root has patched CVE-2026-43048 in the linux package for Root:Debian:11. Multiple fixed versions available.

Root has patched CVE-2026-43048 in the linux package for Root:Debian:12. Multiple fixed versions available.

Root has patched CVE-2026-43048 in the linux package for Root:Ubuntu:22.04. Multiple fixed versions available.

Root has patched CVE-2026-43048 in the linux package for Root:Ubuntu:24.04. Multiple fixed versions available.

In the Linux kernel, the following vulnerability has been resolved: HID: core: Mitigate potential OOB by removing bogus memset() The memset() in hid_report_raw_event() has the good intention of clearing out bogus data by zeroing the area from the end of the incoming data string to the assumed end of the buffer. However, as we have previously seen, doing so can easily result in OOB reads and writes in the subsequent thread of execution. The current suggestion from one of the HID maintainers is to remove the memset() and simply return if the incoming event buffer size is not large enough to fill the associated report. Suggested-by Benjamin Tissoires [email protected] [bentiss: changed the return value]

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

HID: core: Mitigate potential OOB by removing bogus memset()

The memset() in hid_report_raw_event() has the good intention of clearing out bogus data by zeroing the area from the end of the incoming data string to the assumed end of the buffer. However, as we have previously seen, doing so can easily result in OOB reads and writes in the subsequent thread of execution.

The current suggestion from one of the HID maintainers is to remove the memset() and simply return if the incoming event buffer size is not large enough to fill the associated report.

Suggested-by Benjamin Tissoires [email protected]

[bentiss: changed the return value]

• dlm: validate length in dlm_search_rsb_tree {CVE-2026-43125}
• mm/damon/core: validate ranges in damon_set_regions() {CVE-2026-68165}
• netpoll: Fix deadlock in memory allocation under spinlock {CVE-2025-68169}
• drm/amdkfd: Check bounds on CRIU restore queue type and mqd size {CVE-2026-68258}
• gve: fix Rx queue stall on alloc failure {CVE-2026-68129}
• drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved {CVE-2026-68234}
• libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE {CVE-2026-68159}
• media: v4l2-ctrls: validate HEVC active reference counts {CVE-2026-68206}
• drm/i915/hdcp: check streams[] bounds before overflow {CVE-2026-68253}
• drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid() {CVE-2026-68245}
• drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() {CVE-2026-68115}
• drm/i915: Return NULL on error in active_instance {CVE-2026-68248}
• smb: client: validate DFS referral PathConsumed {CVE-2026-68343}
• ext4: fix use-after-free in update_super_work when racing with umount {CVE-2026-31446}
• debugobjects: Plug race against a concurrent OOM disable {CVE-2026-68090}
• HID: wacom: stop hardware after post-start probe failures {CVE-2026-68091}
• drm/xe/pt: Reset current_op in xe_pt_update_ops_init() {CVE-2026-68264}
• net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD {CVE-2026-68288}
• drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON() {CVE-2026-68113}
• openvswitch: fix GSO userspace truncation underflow {CVE-2026-68123}
• drm/amd/display: use kvzalloc to allocate struct dc {CVE-2026-68436}
• drm/i915/gem: Add missing nospec on parallel submit slot {CVE-2026-68269}
• Bluetooth: MGMT: revalidate LOAD_CONN_PARAM queued update {CVE-2026-68394}
• sctp: avoid auth_enable sysctl UAF during netns teardown {CVE-2026-68162}
• wifi: mt76: mt7925: fix crash in reset link replay {CVE-2026-68307}
• Bluetooth: hci_sync: extend conn_hash lookup critical sections {CVE-2026-68393}
• drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU {CVE-2026-68243}
• block: fix memory leak in __blkdev_issue_zero_pages {CVE-2026-68348}
• drm/amdgpu/gfx: fix cleaner shader IB buffer overflow {CVE-2026-68276}
• tracing: Do not call map->ops->elt_free() if elt_alloc() fails {CVE-2026-64173}
• wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin {CVE-2026-68362}
• ovl: check access to copy_file_range source with src mounter creds {CVE-2026-68448}
• drm/nouveau: fix reversed error cleanup order in ucopy functions {CVE-2026-68271}
• vxlan: require CAP_NET_ADMIN in the device netns for changelink {CVE-2026-68432}
• drm/vmwgfx: Validate vmw_surface_metadata::array_size {CVE-2026-68446}
• net: gre: fix lltx regression for GRE tunnels with SEQ/CSUM {CVE-2026-68296}
• Input: elan_i2c - prevent division by zero and arithmetic underflow {CVE-2026-64275}
• iomap: fix out-of-bounds bitmap_set() with zero-length range {CVE-2026-68145}
• vsock: fix lock inversion in vsock_assign_transport() {CVE-2025-40231}
• ASoC: nau8821: Cancel delayed work on component remove {CVE-2026-45963}
• ext4: validate p_idx bounds in ext4_ext_correct_indexes {CVE-2026-31449}
• ipc: fix memleak if msg_init_ns failed in create_ipc_ns {CVE-2024-53175}
• tls: make sure to abort the stream if headers are bogus {CVE-2025-39946}
• ipv6: prevent infinite loop in rt6_nlmsg_size() {CVE-2025-38588}
• gve: fix incorrect buffer cleanup in gve_tx_clean_pending_packets for QPL {CVE-2026-23386}
• xsk: validate MTU against usable frame size on bind {CVE-2026-43092}
• RDMA/irdma: Harden depth calculation functions {CVE-2026-31491}
• iavf: fix out-of-bounds writes in iavf_get_ethtool_stats() {CVE-2026-31505}
• net/ip6_tunnel: Prevent perpetual tunnel growth {CVE-2025-40173}
• net/mlx5: Fix deadlock between devlink lock and esw->wq {CVE-2026-43468}
• mm/damon/sysfs: check contexts->nr before accessing contexts_arr[0] {CVE-2026-31458}
• fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling {CVE-2026-52946}
• nvmet: move async event…

It was discovered that some Arm processors could complete a broadcast translation lookaside buffer (TLB) invalidation before memory writes made through the invalidated translation were globally observed. A local attacker could possibly use this to write to memory after permission to do so had been revoked, bypassing memory protections or escalating privileges. (CVE-2025-10263)

Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems:

• ARM64 architecture;
• User-space API (UAPI);
• Kernel build system;
• ARM32 architecture;
• PowerPC architecture;
• RISC-V architecture;
• S390 architecture;
• User-Mode Linux (UML);
• x86 architecture;
• Cryptographic API;
• Intel NPU Driver;
• Compute Acceleration Framework;
• ACPI drivers;
• Drivers core;
• DRBD Distributed Replicated Block Device drivers;
• Rados block device (RBD) driver;
• Ublk userspace block driver;
• Compressed RAM block device driver;
• Bluetooth drivers;
• Hardware crypto device drivers;
• CXL (Compute Express Link) drivers;
• Arm Firmware Framework for ARMv8-A(FFA);
• EFI core;
• FPGA Framework;
• GPU drivers;
• HID subsystem;
• Hardware monitoring drivers;
• I2C subsystem;
• I3C subsystem;
• InfiniBand drivers;
• Input Device core drivers;
• Input Device (Mouse) drivers;
• IOMMU subsystem;
• Multiple devices driver;
• Media drivers;
• Fastrpc Driver;
• Network drivers;
• Mellanox network drivers;
• Microsoft Azure Network Adapter (MANA) driver;
• MediaTek network drivers;
• NVME drivers;
• Operating Performance Points (OPP) driver;
• PCI subsystem;
• PTP clock framework;
• RPMSG subsystem;
• SCSI subsystem;
• SoundWire subsystem;
• SPI subsystem;
• Greybus lights staging drivers;
• Media staging drivers;
• NVIDIA Tegra embedded controller (NVEC) staging driver;
• Realtek RTL8723BS SDIO drivers;
• TCM subsystem;
• Trusted Execution Environment drivers;
• Thunderbolt and USB4 drivers;
• TTY drivers;
• USB Gadget drivers;
• USB Dual Role (OTG-ready) Controller drivers;
• USB Serial drivers;
• vDPA drivers;
• VFIO drivers;
• Virtio Host (VHOST) subsystem;
• Virtio drivers;
• Xen hypervisor drivers;
• 9P distributed file system;
• AFS file system;
• File systems infrastructure;
• BTRFS file system;
• Ceph distributed file system;
• exFAT file system;
• F2FS file system;
• GFS2 file system;
• HFS file system;
• HFS+ file system;
• JFS file system;
• Network file systems library;
• Network file system (NFS) client;
• Network file system (NFS) server daemon;
• NTFS3 file system;
• OCFS2 file system;
• OrangeFS file system;
• SMB network file system;
• BPF subsystem;
• File system encryption (fscrypt);
• Software nodes and device properties;
• IPv4 networking;
• KVM subsystem;
• Mellanox drivers;
• Memory management;
• Networking core;
• Netfilter;
• Socket messages infrastructure;
• MediaTek SoC drivers;
• Sun RPC protocol;
• Network traffic control;
• IPv6 networking;
• Amateur Radio drivers;
• Bluetooth subsystem;
• IP tunnels definitions;
• KCM (Kernel Connection Multiplexor) sockets driver;
• MultiProtocol Label Switching driver;
• TCP network protocol;
• XFRM subsystem;
• Tracing infrastructure;
• io_uring subsystem;
• Control group (cgroup);
• Perf events;
• IRQ subsystem;
• Locking primitives;
• KProbes tracing;
• 9P file system network protocol;
• B.A.T.M.A.N. meshing protocol;
• Ethernet bridge;
• CAN network layer;
• Ceph Core library;
• Handshake API;
• HSR network protocol;
• IFE protocol;
• L2TP protocol;
• MAC80211 subsystem;
• IEEE 802.15.4 subsystem;
• Multipath TCP;
• NFC subsystem;
• Open vSwitch;
• Phonet protocol;
• RDS protocol;
• RxRPC session sockets;
• SCTP protocol;
• SMC…