CVE-2026-53266

Published Jun 25, 2026

Last updated 5 hours ago

Overview

Description
In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().
Source
416baaa9-dc9f-4396-8d5f-8c081fb06d67
NVD status
Analyzed
Products
linux_kernel

Risk scores

CVSS 3.1

Type
Secondary
Base score
8.8
Impact score
6
Exploitability score
2
Vector string
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Severity
HIGH

Known exploits

Data from CISA

Vulnerability name
Linux Kernel Out-of-Bounds Write Vulnerability
Exploit added on
Sep 18, 2026
Exploit action due
Sep 21, 2026
Required action
Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.

Weaknesses

nvd@nist.gov
NVD-CWE-noinfo
134c704f-9b21-4f2e-91b3-4a467353bcc0
CWE-787

Social media

Hype score
Not currently trending
  1. CISA incluiu 3 falhas do Kernel Linux no KEV: CVE-2025-39682, CVE-2026-53266 e CVE-2025-39964. Há exploração ativa confirmada. Priorize patches em infraestrutura crítica e cloud. https://t.co/1WXKxIiZdW https://t.co/eJQmiyvUfQ

    @luizlcsec

    19 Sept 2026

    0 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  2. Three Linux kernel vulnerabilities. All confirmed exploited by CISA on the same day. CVE-2025-39682 (CVSS 9.8): a remotely triggerable flaw in the TLS receive path. CVE-2026-53266 (8.8): an out-of-bounds write in netfilter's ebtables ARP rewrite. CVE-2025-39964 (7.8): a race htt

    @vuln_tracker

    19 Sept 2026

    16 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  3. CISA added 3 Linux kernel flaws to KEV: CVE-2025-39682, CVE-2026-53266, and CVE-2025-39964. Red Hat confirms public exploits exist. Patch host kernels immediately. Source: https://t.co/OrlDmJvsEr Intel: https://t.co/QC14eBVf0C #2workly

    @2Workly

    19 Sept 2026

    2 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  4. Three severe Linux kernel vulnerabilities—CVE-2025-39682, CVE-2026-53266 & CVE-2025-39964—are now confirmed exploited in the wild. Red Hat’s advisories are live. US agencies face a patch deadline of September 21 under CISA’s KEV and BOD-26-04 mandates. Threats span pr

    @dailytechonx

    19 Sept 2026

    31 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  5. CISA put 3 Linux kernel flaws on KEV yesterday—actively exploited. Federal due: Sep 21. CVE-2025-39682 (TLS zero-length rx_list), CVE-2026-53266 (ebtables SNAT ARP → OOB write), CVE-2025-39964 (AF_ALG race). Linux self-hosters/cloud VMs: update weekend, not “wait for LTS

    @Sunil_kumawat17

    19 Sept 2026

    51 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    1 Reply

    0 Quotes

  6. 米国サイバーセキュリティ・社会基盤安全保障庁(CISA)が既知の悪用された脆弱性カタログに2件と1件の脆弱性を追加。全てLinuxカーネルで、CVE-2025-39964、CVE-2026-53266、CVE-2025-39682。対処期限は3日後の9/21。ランサ

    @__kokumoto

    19 Sept 2026

    1018 Impressions

    1 Retweet

    4 Likes

    7 Bookmarks

    2 Replies

    0 Quotes

  7. CISA put two Linux Kernel bugs on KEV today (CVE-2025-39964, CVE-2026-53266). Active exploitation. Federal due Sep 21. They hit every Linux fleet — VMs, NAS, firewalls, containers. Patch or rebuild, then check for prior compromise. https://t.co/ipqh8oJ6Q5

    @bluefortit

    19 Sept 2026

    3 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  8. CISA adds two actively exploited Linux Kernel vulnerabilities (CVE-2025-39964 & CVE-2026-53266) to the KEV Catalog. Federal agencies must prioritize patching these threats under BOD 26-04. Stay ahead with SOC Minute updates. #CISA #LinuxKernel #PatchManagement https://t.co/Pf

    @SOCMinute

    18 Sept 2026

    26 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  9. CISA put two Linux kernel bugs on KEV today: CVE-2025-39964 (af_alg concurrent-write race) and CVE-2026-53266 (ebt_snat ARP rewrite on bridge netfilter). Already exploited — not a theoretical advisory pile. If your fleet still treats kernel updates like quarterly hygiene, thes

    @Chris_L_Elliott

    18 Sept 2026

    37 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  10. News: CISA put Linux kernel CVE-2025-39964 (AF_ALG race) and CVE-2026-53266 (ebtables SNAT write) on KEV Sep 18. Hits unpatched Linux hosts; both under active use. Apply your distro kernel update now; if stuck, blacklist af_alg and drop ebtables ARP rewrite.

    @snakeyesV1

    18 Sept 2026

    61 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  11. 🚨 CVE-2026-53266 — HIGH — actively exploited per CISA KEV Linux Kernel CVSS 8.8 | EPSS 0% #Linux #CVE https://t.co/RwwlLHMvAq

    @threatpodium

    18 Sept 2026

    2 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  12. Linux kernel CISA KEV (today): CVE-2025-39964 and CVE-2026-53266. AF_ALG race condition and out-of-bounds write. CISA cites active exploitation evidence. Patch or roll vendor kernel updates across managed Linux fleets now. #CVE #KEV

    @HoustonIntrove1

    18 Sept 2026

    29 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  13. 🔒 #CyberSecurity CISA KEV Alert: CVE-2025-39964 and CVE-2026-53266 Linux Kernel Exploits — Detec… "On September 18, 2026, CISA added two Linux kernel vulnerabilities to its Known Exploited…" 🔗 https://t.co/J5PKZ0z0Ml #CyberSecurity #ThreatIntel #critical #zeroday

    @SecurityAr58409

    18 Sept 2026

    35 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  14. TRC analysis shows attackers exploiting Linux kernel vulnerabilities CVE-2025-39964 and CVE-2026-53266 to gain root privileges and move laterally across network segments. Runtime segmentation helps contain post-compromise activity when kernel-level access is achieved. #ZeroTrust

    @aviatrixtrc

    18 Sept 2026

    50 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  15. 【緊急】Linuxカーネルに悪用確認済みの脆弱性2件(CVE-2025-39964 / CVE-2026-53266) CISAが9/18にKEV追加、期限は9/21。 対処: ディストリのトラッカーで自分の版が修正済みかを確認し、更新して再起動。 https://t.co/6Gqy

    @ForsmileDNet

    18 Sept 2026

    5 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  16. 🔒 #CyberSecurity CVE-2026-53266: Linux Kernel ebtables SNAT Out-of-Bounds Write Under Active Exp… "On September 18, 2026, CISA added CVE-2026-53266 to the Known Exploited…" 🔗 https://t.co/6iTBHya7a7 #CyberSecurity #ThreatIntel #cve202653266 #critical #cisakev

    @SecurityAr58409

    18 Sept 2026

    26 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  17. 🛡 We added Linux Kernal race condition vulnerability CVE-2025-39964 & out-of-bounds write vulnerability CVE-2026-53266 to our KEV Catalog. Visit https://t.co/myxOwap1Tf & apply mitigations to protect your org from cyberattacks. #Cybersecurity #InfoSec https://t.co/SpBC

    @CISACyber

    18 Sept 2026

    5384 Impressions

    3 Retweets

    16 Likes

    4 Bookmarks

    1 Reply

    0 Quotes

  18. 🔴 CISA Adds Two Linux Kernel Vulnerabilities to Known Exploited List CISA added CVE-2025-39964 (Linux kernel race condition) and CVE-2026-53266 (Linux kernel out-of-bounds write) to its Known Exploited Vulnerabilities Catalog based on active exploitation evidence. Binding htt

    @NewsTongueX

    18 Sept 2026

    41 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

Configurations

  1. In the Linux kernel, the following vulnerability has been resolved: usb: misc: usbio: fix disconnect UAF in client teardown usbio_disconnect() walks usbio->cli_list in reverse and uninitializes each auxiliary device. auxiliary_device_uninit() drops the device reference, and for an unbound child that can run usbio_auxdev_release() and free the containing struct usbio_client. list_for_each_entry_reverse() advances after the loop body by reading client->link.prev. If the current client is freed by auxiliary_device_uninit(), the iterator dereferences freed memory. Use list_for_each_entry_safe_reverse() so the previous client is cached before the body can drop the final reference. This preserves reverse teardown order while keeping the next iterator cursor independent of the current client's lifetime. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in usbio_disconnect+0x12e/0x150 Call Trace: <TASK> dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? usbio_disconnect+0x12e/0x150 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x188/0x320 ? usbio_disconnect+0x12e/0x150 kasan_report+0xe0/0x110 ? usbio_disconnect+0x12e/0x150 usbio_disconnect+0x12e/0x150 usb_unbind_interface+0xf3/0x400 really_probe+0x316/0x660 __driver_probe_device+0x106/0x240 driver_probe_device+0x4a/0x110 __device_attach_driver+0xf1/0x1a0 ? __pfx___device_attach_driver+0x10/0x10 bus_for_each_drv+0xf9/0x160 ? __pfx_bus_for_each_drv+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? trace_hardirqs_on+0x18/0x130 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_spin_unlock_irqrestore+0x44/0x60 __device_attach+0x133/0x2a0 ? __pfx___device_attach+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_raw_spin_unlock+0x9a/0x100 ? srso_alias_return_thunk+0x5/0xfbef5 device_initial_probe+0x55/0x70 bus_probe_device+0x4a/0xd0 device_add+0x9b9/0xc10 ? __pfx_device_add+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x44/0x60 ? srso_alias_return_thunk+0x5/0xfbef5 ? lockdep_hardirqs_on_prepare+0xea/0x1a0 ? srso_alias_return_thunk+0x5/0xfbef5 ? usb_enable_lpm+0x3c/0x260 usb_set_configuration+0xb64/0xf20 usb_generic_driver_probe+0x5f/0x90 usb_probe_device+0x71/0x1b0 really_probe+0x46b/0x660 __driver_probe_device+0x106/0x240 driver_probe_device+0x4a/0x110 __device_attach_driver+0xf1/0x1a0 ? __pfx___device_attach_driver+0x10/0x10 bus_for_each_drv+0xf9/0x160 ? __pfx_bus_for_each_drv+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? trace_hardirqs_on+0x18/0x130 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_spin_unlock_irqrestore+0x44/0x60 __device_attach+0x133/0x2a0 ? __pfx___device_attach+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_raw_spin_unlock+0x9a/0x100 ? srso_alias_return_thunk+0x5/0xfbef5 device_initial_probe+0x55/0x70 bus_probe_device+0x4a/0xd0 device_add+0x9b9/0xc10 ? __pfx_device_add+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? add_device_randomness+0xb7/0xf0 usb_new_device+0x492/0x870 hub_event+0x1b10/0x29c0 ? __pfx_hub_event+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_acquire+0x187/0x300 ? process_one_work+0x475/0xb90 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_release+0xc8/0x290 ? srso_alias_return_thunk+0x5/0xfbef5 process_one_work+0x4d7/0xb90 ? __pfx_process_one_work+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? __list_add_valid_or_report+0x37/0xf0 ? __pfx_hub_event+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x2d8/0x570 ? __pfx_worker_thread+0x10/0x10 kthread+0x1ad/0x1f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c9/0x540 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x2e9/0x730 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK>CVE-2026-64453
  2. In the Linux kernel, the following vulnerability has been resolved: tracing: Fix NULL pointer dereference in func_set_flag() func_set_flag() dereferences tr->current_trace_flags before verifying that the current tracer is actually the function tracer. When the active tracer has been switched away from "function" (e.g., to "wakeup_rt"), tr->current_trace_flags can be NULL, leading to a NULL pointer dereference and kernel crash. The call chain that triggers this is: trace_options_write() -> __set_tracer_option() -> trace->set_flag() /* func_set_flag */ In func_set_flag(), the first operation is: if (!!set == !!(tr->current_trace_flags->val & bit)) This dereferences tr->current_trace_flags unconditionally. The safety check that guards against a non-function tracer: if (tr->current_trace != &function_trace) return 0; is placed *after* the dereference, which is too late. This was observed with the following crash dump: BUG: unable to handle page fault at 0000000000000000 RIP: func_set_flag+0xd Call Trace: __set_tracer_option+0x27 trace_options_write+0x75 vfs_write+0x12a ksys_write+0x66 do_syscall_64+0x5b RIP: ffffffff914c973d RSP: ff67ec88b01dfdf0 RFLAGS: 00010202 RAX: 0000000000000000 RBX: ff3a826e80354580 RCX: 0000000000000001 RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffffff93918080 The disassembly confirms the fault: func_set_flag+0: mov 0x1f08(%rdi), %rax ; RAX = tr->current_trace_flags = NULL func_set_flag+13: mov (%rax), %eax ; page fault: dereference NULL At the time of the crash: tr->current_trace_flags = 0x0 (NULL) tr->current_trace = wakeup_rt_tracer (not function_trace) The scenario is that a process opens a function tracer option file (such as "func_stack_trace"), then the current tracer is switched to another tracer (e.g., "wakeup_rt"), which sets current_trace_flags to NULL. When the process subsequently writes to the option file, func_set_flag() is invoked and crashes on the NULL dereference. Fix this by moving the current_trace check before the current_trace_flags dereference, so that func_set_flag() returns early when the function tracer is not active.CVE-2026-64451
  3. In the Linux kernel, the following vulnerability has been resolved: tipc: fix out-of-bounds read in broadcast Gap ACK blocks A broadcast PROTOCOL/STATE_MSG can carry a Gap ACK blocks record in its data area. tipc_get_gap_ack_blks() only verifies that the record's len field is self-consistent with its ugack_cnt/bgack_cnt counts (sz == struct_size(p, gacks, ugack_cnt + bgack_cnt)); it does not check that the record actually fits in the message data area, msg_data_sz(). The unicast caller tipc_link_proto_rcv() bounds it ("if (glen > dlen) break;"), but the broadcast caller tipc_bcast_sync_rcv() discards the returned size, so tipc_link_advance_transmq() copies the record off the receive skb with an attacker-controlled count: this_ga = kmemdup(ga, struct_size(ga, gacks, ga->bgack_cnt), GFP_ATOMIC); A TIPC neighbour that negotiated TIPC_GAP_ACK_BLOCK triggers it with one ordinary broadcast STATE_MSG (msg_bc_ack_invalid() clear), sized so its data area is short, carrying a Gap ACK record with len = 0x400, bgack_cnt = 0xff and ugack_cnt = 0. len then equals struct_size(p, gacks, 255), so the consistency check passes and ga is non-NULL; kmemdup() reads struct_size(ga, gacks, 255) = 1024 bytes out of the much smaller skb: BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x48/0x60 Read of size 1024 at addr ffff0000c7030d38 by task poc864/69 Call trace: kmemdup_noprof+0x48/0x60 tipc_link_advance_transmq+0x86c/0xb80 tipc_link_bc_ack_rcv+0x19c/0x1e0 tipc_bcast_sync_rcv+0x1c4/0x2c4 tipc_rcv+0x85c/0x1340 tipc_l2_rcv_msg+0xac/0x104 The buggy address belongs to the object at ffff0000c7030d00 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 56 bytes inside of allocated 704-byte region [ffff0000c7030d00, ffff0000c7030fc0) The copied-out bytes are subsequently consumed as gap/ack values, but the read is already out of bounds at the kmemdup() regardless of how they are used. The unicast STATE path drops such a message: "if (glen > dlen) break;" skips the rest of STATE_MSG handling and the skb is freed. Make the broadcast path drop it too. tipc_bcast_sync_rcv() now bounds the record against msg_data_sz() and, when it does not fit, reports it back through tipc_node_bc_sync_rcv() to tipc_rcv() so the skb is discarded rather than processed. ga is not cleared on this path: ga == NULL already means "legacy peer without Selective ACK", a distinct legitimate state.CVE-2026-64450
  4. In the Linux kernel, the following vulnerability has been resolved: staging: vme_user: bound slave read/write to the kern_buf size The SLAVE-path helpers buffer_to_user() and buffer_from_user() copy 'count' bytes into/out of the fixed-size kern_buf (size_buf == PCI_BUF_SIZE == 0x20000, 128 KiB) using *ppos as the offset, without bounding *ppos + count against size_buf. vme_user_write()/vme_user_read() only clamp count to the VME window size (image_size = vme_get_size(resource)), which VME_SET_SLAVE sets from the user-supplied slave.size -- validated against the VME address space (up to VME_A32_MAX = 4 GiB), not against PCI_BUF_SIZE. When the window exceeds 128 KiB, a write()/read() copies past the kern_buf allocation. Clamp count against size_buf in both helpers, with an early return when *ppos is already at/after the buffer end. *ppos is >= 0 here (the caller rejects negative offsets), so size_buf - *ppos cannot wrap. This mirrors the existing clamp in the MASTER-path helpers resource_to_user() / resource_from_user(), and matches the read()/write() convention of a short transfer at end-of-buffer. Found by static analysis (CodeQL taint tracking + CBMC bounded model checking) and confirmed dynamically under KASAN with the vme_fake bridge: BUG: KASAN: slab-out-of-bounds in _copy_from_user+0x2d/0x80 Write of size 262144 at addr ffff888004100000 by task trigger/68 _copy_from_user+0x2d/0x80 vme_user_write+0x13e/0x240 [vme_user] vfs_write+0x1b8/0x7a0 ksys_write+0xb8/0x150CVE-2026-64449