CVE-2026-46333

In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional "drop capabilities" model doesn't make any difference for this all. Make it all make a bit more sense by saying that if you don't have a MM pointer, we'll use a cached "last dumpability" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.

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 kernel packages contain the Linux kernel, the core of any Linux operating system.

Security Fix(es):

• kernel: net/sched: Make cake_enqueue return NET_XMIT_CN when past buffer_limit (CVE-2025-39766)

• kernel: scsi: qla2xxx: Fix improper freeing of purex item (CVE-2025-68741)

• kernel: libceph: make decode_pool() more resilient against corrupted osdmaps (CVE-2025-71116)

• kernel: libceph: prevent potential out-of-bounds reads in handle_auth_done() (CVE-2026-22984)

• kernel: libceph: replace overzealous BUG_ON in osdmap_apply_incremental() (CVE-2026-22990)

• kernel: Linux kernel: Denial of Service in libceph OSD client due to unreset sparse-read state (CVE-2026-23136)

• kernel: net/sched: cls_u32: use skb_header_pointer_careful() (CVE-2026-23204)

• kernel: Linux kernel: Use-after-free in traffic control (act_ct) may lead to denial of service or privilege escalation (CVE-2026-23270)

• kernel: Linux kernel KVM: Privilege escalation or denial of service due to improper shadow page table entry handling (CVE-2026-23401)

• kernel: nfsd: fix heap overflow in NFSv4.0 LOCK replay cache (CVE-2026-31402)

• kernel: can: raw: fix ro->uniq use-after-free in raw_rcv() (CVE-2026-31532)

• kernel: usbip: validate number_of_packets in usbip_pack_ret_submit() (CVE-2026-31607)

• kernel: md/bitmap: fix GPF in write_page caused by resize race (CVE-2026-43163)

• kernel: RDMA/umem: Fix double dma_buf_unpin in failure path (CVE-2026-43128)

• kernel: "Dirty Frag" is a new universal Local Privilege Escalation (LPE) vulnerability in the Linux kernel (CVE-2026-43284)

• kernel: "Fragnesia" is a variant of Dirty Frag vulnerability in the ESP/XFRM leading to Local Privilege Escalation (LPE) vulnerability in the Linux kernel (CVE-2026-46300)

• kernel: Read root-owned files as an unprivileged user (CVE-2026-46333)

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.

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

Security Fix(es):

• kernel: net: af_can: do not leave a dangling sk pointer in can_create() (CVE-2024-56603)

• kernel: net/sched: Make cake_enqueue return NET_XMIT_CN when past buffer_limit (CVE-2025-39766)

• kernel: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id (CVE-2025-68724)

• kernel: scsi: qla2xxx: Fix improper freeing of purex item (CVE-2025-68741)

• kernel: Linux kernel: Use-after-free in traffic control (act_ct) may lead to denial of service or privilege escalation (CVE-2026-23270)

• kernel: Linux kernel KVM: Privilege escalation or denial of service due to improper shadow page table entry handling (CVE-2026-23401)

• kernel: nfsd: fix heap overflow in NFSv4.0 LOCK replay cache (CVE-2026-31402)

• kernel: Bluetooth: SCO: Fix use-after-free in sco_recv_frame() due to missing sock_hold (CVE-2026-31408)

• kernel: usbip: validate number_of_packets in usbip_pack_ret_submit() (CVE-2026-31607)

• kernel: RDMA/umem: Fix double dma_buf_unpin in failure path (CVE-2026-43128)

• kernel: "Dirty Frag" is a new universal Local Privilege Escalation (LPE) vulnerability in the Linux kernel (CVE-2026-43284)

• kernel: "Fragnesia" is a variant of Dirty Frag vulnerability in the ESP/XFRM leading to Local Privilege Escalation (LPE) vulnerability in the Linux kernel (CVE-2026-46300)

• kernel: Read root-owned files as an unprivileged user (CVE-2026-46333)

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.

The kernel-rt packages provide the Real Time Linux Kernel, which enables fine-tuning for systems with extremely high determinism requirements.

Security Fix(es):

• kernel: "Fragnesia" is a variant of Dirty Frag vulnerability in the ESP/XFRM leading to Local Privilege Escalation (LPE) vulnerability in the Linux kernel (CVE-2026-46300)

• kernel: Read root-owned files as an unprivileged user (CVE-2026-46333)

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.

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

Security Fix(es):

• kernel: "Fragnesia" is a variant of Dirty Frag vulnerability in the ESP/XFRM leading to Local Privilege Escalation (LPE) vulnerability in the Linux kernel (CVE-2026-46300)

• kernel: Read root-owned files as an unprivileged user (CVE-2026-46333)

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.

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

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

In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional "drop capabilities" model doesn't make any difference for this all. Make it all make a bit more sense by saying that if you don't have a MM pointer, we'll use a cached "last dumpability" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.

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

Security Fix(es):

• kernel: net/sched: Make cake_enqueue return NET_XMIT_CN when past buffer_limit (CVE-2025-39766)
• kernel: scsi: qla2xxx: Fix improper freeing of purex item (CVE-2025-68741)
• kernel: libceph: make decode_pool() more resilient against corrupted osdmaps (CVE-2025-71116)
• kernel: libceph: prevent potential out-of-bounds reads in handle_auth_done() (CVE-2026-22984)
• kernel: libceph: replace overzealous BUG_ON in osdmap_apply_incremental() (CVE-2026-22990)
• kernel: Linux kernel: Denial of Service in libceph OSD client due to unreset sparse-read state (CVE-2026-23136)
• kernel: net/sched: cls_u32: use skb_header_pointer_careful() (CVE-2026-23204)
• kernel: Linux kernel: Use-after-free in traffic control (act_ct) may lead to denial of service or privilege escalation (CVE-2026-23270)
• kernel: Linux kernel KVM: Privilege escalation or denial of service due to improper shadow page table entry handling (CVE-2026-23401)
• kernel: nfsd: fix heap overflow in NFSv4.0 LOCK replay cache (CVE-2026-31402)
• kernel: can: raw: fix ro->uniq use-after-free in raw_rcv() (CVE-2026-31532)
• kernel: usbip: validate number_of_packets in usbip_pack_ret_submit() (CVE-2026-31607)
• kernel: md/bitmap: fix GPF in write_page caused by resize race (CVE-2026-43163)
• kernel: RDMA/umem: Fix double dma_buf_unpin in failure path (CVE-2026-43128)
• kernel: "Dirty Frag" is a new universal Local Privilege Escalation (LPE) vulnerability in the Linux kernel (CVE-2026-43284)
• kernel: "Fragnesia" is a variant of Dirty Frag vulnerability in the ESP/XFRM leading to Local Privilege Escalation (LPE) vulnerability in the Linux kernel (CVE-2026-46300)
• kernel: Read root-owned files as an unprivileged user (CVE-2026-46333)

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.

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

Security Fix(es):

• kernel: net: af_can: do not leave a dangling sk pointer in can_create() (CVE-2024-56603)
• kernel: net/sched: Make cake_enqueue return NET_XMIT_CN when past buffer_limit (CVE-2025-39766)
• kernel: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id (CVE-2025-68724)
• kernel: scsi: qla2xxx: Fix improper freeing of purex item (CVE-2025-68741)
• kernel: Linux kernel: Use-after-free in traffic control (act_ct) may lead to denial of service or privilege escalation (CVE-2026-23270)
• kernel: Linux kernel KVM: Privilege escalation or denial of service due to improper shadow page table entry handling (CVE-2026-23401)
• kernel: nfsd: fix heap overflow in NFSv4.0 LOCK replay cache (CVE-2026-31402)
• kernel: Bluetooth: SCO: Fix use-after-free in sco_recv_frame() due to missing sock_hold (CVE-2026-31408)
• kernel: usbip: validate number_of_packets in usbip_pack_ret_submit() (CVE-2026-31607)
• kernel: RDMA/umem: Fix double dma_buf_unpin in failure path (CVE-2026-43128)
• kernel: "Dirty Frag" is a new universal Local Privilege Escalation (LPE) vulnerability in the Linux kernel (CVE-2026-43284)
• kernel: "Fragnesia" is a variant of Dirty Frag vulnerability in the ESP/XFRM leading to Local Privilege Escalation (LPE) vulnerability in the Linux kernel (CVE-2026-46300)
• kernel: Read root-owned files as an unprivileged user (CVE-2026-46333)

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.

The kernel-rt packages provide the Real Time Linux Kernel, which enables fine-tuning for systems with extremely high determinism requirements.

Security Fix(es):

• kernel: "Fragnesia" is a variant of Dirty Frag vulnerability in the ESP/XFRM leading to Local Privilege Escalation (LPE) vulnerability in the Linux kernel (CVE-2026-46300)
• kernel: Read root-owned files as an unprivileged user (CVE-2026-46333)

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.

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

Security Fix(es):

• kernel: "Fragnesia" is a variant of Dirty Frag vulnerability in the ESP/XFRM leading to Local Privilege Escalation (LPE) vulnerability in the Linux kernel (CVE-2026-46300)
• kernel: Read root-owned files as an unprivileged user (CVE-2026-46333)

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.

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

Security Fix(es):

• kernel: net: skbuff: propagate shared-frag marker through frag-transfer helpers (CVE-2026-46300)
• kernel: ptrace: require CAP_SYS_PTRACE when task has no mm (CVE-2026-46333)

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.

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

Security Fix(es):

• kernel: net: skbuff: propagate shared-frag marker through frag-transfer helpers (CVE-2026-46300)
• kernel: ptrace: require CAP_SYS_PTRACE when task has no mm (CVE-2026-46333)

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.

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

Security Fix(es):

• kernel: net: skbuff: propagate shared-frag marker through frag-transfer helpers (CVE-2026-46300)
• kernel: ptrace: require CAP_SYS_PTRACE when task has no mm (CVE-2026-46333)

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.

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

ptrace: slightly saner 'get_dumpable()' logic

The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm.

And almost all users do in fact use it only for the case where the task has a mm pointer.

But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads).

It's not what this flag was designed for, but it is what it is.

The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional "drop capabilities" model doesn't make any difference for this all.

Make it all make a bit more sense by saying that if you don't have a MM pointer, we'll use a cached "last dumpability" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.

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

ptrace: slightly saner 'get_dumpable()' logic

The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm.

And almost all users do in fact use it only for the case where the task has a mm pointer.

But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads).

It's not what this flag was designed for, but it is what it is.

The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional "drop capabilities" model doesn't make any difference for this all.

Make it all make a bit more sense by saying that if you don't have a MM pointer, we'll use a cached "last dumpability" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.

• ptrace: require CAP_SYS_PTRACE when task has no mm {CVE-2026-46333}

• ptrace: require CAP_SYS_PTRACE when task has no mm {CVE-2026-46333}

• ptrace: require CAP_SYS_PTRACE when task has no mm {CVE-2026-46333}

• ptrace: require CAP_SYS_PTRACE when task has no mm {CVE-2026-46333}

• CVE-2026-46333
  • ptrace: require CAP_SYS_PTRACE when task has no mm
• CVE-2026-46300
  • net: skbuff: propagate shared-frag marker through copy/coalesce/gro/shift paths
• CVE-2026-31532
  • can: raw: fix ro->uniq use-after-free in raw_rcv() {CVE-2026-31532}

[ Ubuntu: 4.15.0-256.267 ]

• CVE-2026-46333
  • ptrace: require CAP_SYS_PTRACE when task has no mm {CVE-2026-46333}
• CVE-2026-46300
  • net: skbuff: propagate shared-frag marker through copy/coalesce/gro/shift paths {CVE-2026-46300}
• CVE-2026-43284
  • xfrm: esp: avoid in-place decrypt on shared skb frags {CVE-2026-43284}
• Packaging
  • Adopt +tuxcare.elsN versioning scheme
• Bump ABI 4.15.0-257

[ Ubuntu: 4.15.0-256.267 ]

• CVE-2026-46333
  • ptrace: require CAP_SYS_PTRACE when task has no mm {CVE-2026-46333}
• CVE-2026-46300
  • net: skbuff: propagate shared-frag marker through copy/coalesce/gro/shift paths {CVE-2026-46300}
• CVE-2026-43284
  • xfrm: esp: avoid in-place decrypt on shared skb frags {CVE-2026-43284}
• Packaging
  • Adopt +tuxcare.elsN versioning scheme
• Bump ABI 4.15.0-257