CVE-2025-39682

Published Sep 5, 2025

Last updated a day ago

Overview

AI description

Automated description summarized from trusted sources.

CVE-2025-39682 is a vulnerability found in the Linux kernel's Transport Layer Security (TLS) subsystem. The flaw specifically affects the handling of zero-length records within the `rx_list` during the `recvmsg()` process. This issue arises from a corner case where an initial zero-length record, pulled from the `rx_list`, disrupts assumptions made by the `recvmsg()` logic regarding zero-copy decryption and transitions between record types. This mishandling can lead to memory corruption and a use-after-free condition within the kernel's TLS receive path. A local, authenticated user can exploit this vulnerability by crafting a specific TLS traffic pattern that leaves a zero-length record queued on the `rx_list`, subsequently triggering the vulnerable code path during a `recvmsg()` call.

Description
In the Linux kernel, the following vulnerability has been resolved: tls: fix handling of zero-length records on the rx_list Each recvmsg() call must process either - only contiguous DATA records (any number of them) - one non-DATA record If the next record has different type than what has already been processed we break out of the main processing loop. If the record has already been decrypted (which may be the case for TLS 1.3 where we don't know type until decryption) we queue the pending record to the rx_list. Next recvmsg() will pick it up from there. Queuing the skb to rx_list after zero-copy decrypt is not possible, since in that case we decrypted directly to the user space buffer, and we don't have an skb to queue (darg.skb points to the ciphertext skb for access to metadata like length). Only data records are allowed zero-copy, and we break the processing loop after each non-data record. So we should never zero-copy and then find out that the record type has changed. The corner case we missed is when the initial record comes from rx_list, and it's zero length.
Source
416baaa9-dc9f-4396-8d5f-8c081fb06d67
NVD status
Undergoing Analysis
Products
linux_kernel, debian_linux

Risk scores

CVSS 3.1

Type
Primary
Base score
7.1
Impact score
5.2
Exploitability score
1.8
Vector string
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
Severity
HIGH

Known exploits

Data from CISA

Vulnerability name
Linux Kernel Improper Check for Unusual or Exceptional Conditions 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-Other
134c704f-9b21-4f2e-91b3-4a467353bcc0
CWE-754

Social media

Hype score is a measure of social media activity compared against trending CVEs from the past 12 months. Max score 100.

Hype score

19

  1. @CISAgov adds three actively exploited Linux Kernel flaws to the KEV catalog. CVE-2025-39682 affects kTLS zero-length record handling. CVE-2026-53266 triggers an out-of-bounds write in ebtables ARP processing. CVE-2025-39964 is a race condition in AF_ALG sockets. Patch

    @WorldCyberNewsX

    20 Sept 2026

    2 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  2. CISA Flags Three Linux Kernel Vulnerabilities Exploited in the Wild | The Hacker News https://t.co/IANuqzO6jf • CVE-2025-39682 (CVSS 9.8) — Improper check for unusual or exceptional conditions in the TLS receive path; lets local authenticated users trigger memory disclosure

    @igor_os777

    19 Sept 2026

    706 Impressions

    1 Retweet

    10 Likes

    2 Bookmarks

    2 Replies

    0 Quotes

  3. TRC analysis shows attackers are chaining three Linux kernel exploits (CVE-2025-39682, CVE-2026-53266, CVE-2025-39964) for privilege escalation and lateral movement across containerized workloads. Runtime segmentation helps contain post-compromise activity in these scenarios.

    @aviatrixtrc

    19 Sept 2026

    48 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  4. TRC analysis shows attackers exploiting CVE-2025-39682 to gain kernel-level access on Linux systems, then pivoting laterally through cloud workloads via unencrypted east-west traffic. Runtime segmentation helps contain post-compromise movement across cloud infrastructure.

    @aviatrixtrc

    19 Sept 2026

    44 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  5. 🚨 CISA flags a critical Linux kernel TLS flaw as actively exploited. CVE-2025-39682 is now in the KEV catalog, with federal agencies facing a Sept. 21 remediation deadline. 🔎 https://t.co/LtrWSg9KCD #CyberSecurity #Linux

    @BadgerSignalHQ

    19 Sept 2026

    16 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  6. 🚨 ROOT ON YOUR LINUX BOXES: Check your kernels right now. CISA just threw multiple Linux privilege escalation bugs (CVE-2026-53266, CVE-2025-39964, CVE-2025-39682) into the Known Exploited Vulnerabilities catalog under emergency mandates. What’s happening? Attackers who h

    @reach2ratan

    19 Sept 2026

    584 Impressions

    15 Retweets

    25 Likes

    10 Bookmarks

    0 Replies

    0 Quotes

  7. https://t.co/N4U33GRATd CISA added CVE-2025-39682, a Linux kernel TLS receive-path flaw, to its Known Exploited Vulnerabilities catalogue on 18 September 2026. The entry sets a 21 September due date and requires forensic triage under BOD 26-04 for federal civilian agencies,

    @Read0nlyNet

    19 Sept 2026

    4 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  8. 🚨 CVE-2025-39682 — Linux Kernel TLS (kTLS), memory corruption in the receive path What broke: Linux has a feature called kernel TLS (kTLS) that lets the kernel itself handle decrypting TLS-encrypted network traffic, instead of leaving that work entirely to an application in

    @YourDailyCVE

    19 Sept 2026

    77 Impressions

    0 Retweets

    1 Like

    0 Bookmarks

    1 Reply

    0 Quotes

  9. 🔒 #CyberSecurity CVE-2025-39682: Linux Kernel TLS Receive Path Flaw Added to CISA KEV — Detectio… "On Friday, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added three…" 🔗 https://t.co/uXaxOOQGS7 #CyberSecurity #ThreatIntel #critical #zeroday #c

    @SecurityAr58409

    19 Sept 2026

    32 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  10. CISA added CVE-2025-39682, a Linux kernel flaw, to its Known Exploited Vulnerabilities catalog based on active exploitation evidence. Prioritize patching affected Linux systems and review logs for prior compromise. Source: https://t.co/jrp6JGsona

    @dclx0

    19 Sept 2026

    0 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  11. 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

    1 Impression

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  12. 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

    268 Impressions

    0 Retweets

    5 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  13. 🚨 CISA alerte sur l’exploitation active de 3 failles critiques du noyau Linux : patch d’urgence avant le 21 septembre 2026. La CVE-2025-39682 : 9.8 (Critical) selon https://t.co/gtBj4NE6L3. #zoneantimalware https://t.co/0nfjQAUlIF

    @NicolasCoolman

    19 Sept 2026

    37 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  14. 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

    9 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  15. CISA added 3 exploited Linux kernel CVEs to KEV, incl. CVE-2025-39682 (CVSS 9.8). First step: check running kernel versions against these CVEs and confirm patch status before any applicable deadlines. https://t.co/nvp4UjPy4Q https://t.co/ZEoiZ2jCD8

    @OrizonSignals

    19 Sept 2026

    34 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  16. 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

    60 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  17. SecBoard Daily · 18 September 2026 Top story: CISA Adds One Known Exploited Vulnerability to Catalog (CVE-2025-39682, actively exploited) 2 newly listed as exploited Full daily briefing on SecBoard – address in the image. #ThreatIntel https://t.co/3KvEH4MPsn

    @BytesNora

    19 Sept 2026

    19 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  18. 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

    73 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    1 Reply

    0 Quotes

  19. 🔒 #CyberSecurity CVE-2025-39682: Linux Kernel TLS Receive Path Flaw Under Active Exploitation — … "On September 18, 2026, CISA added CVE-2025-39682 to the Known Exploited…" 🔗 https://t.co/IkjWTFyW5Z #CyberSecurity #ThreatIntel #cve202539682 #critical #cisakev

    @SecurityAr58409

    19 Sept 2026

    51 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

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

    @__kokumoto

    19 Sept 2026

    1185 Impressions

    1 Retweet

    6 Likes

    7 Bookmarks

    2 Replies

    0 Quotes

  21. KEVに追加されたLinux KernelのCVE-2025-39682は - Ubuntu 24.04 - Ubuntu 22.04でHWE 6.8カーネルを使用している環境 - RHEL 9/10 あたりに影響が有りそう。リモート攻撃には、OpenSSLのkTLS対応など、受信側でkTLSを実際に利用する

    @shojiueda

    19 Sept 2026

    221 Impressions

    1 Retweet

    3 Likes

    1 Bookmark

    0 Replies

    0 Quotes

  22. CVE-2025-39682: Critical Linux Kernel KTLS Zero-Length Record Flaw A critical flaw in the Linux Kernel TLS receive path (CVE-2025-39682) allows unauthenticated remote memory corruption via crafted… Full write-up → link in bio #cybersecurity #infosec #cve #kev #linux https:/

    @HotaSamit

    19 Sept 2026

    32 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  23. 🚨 CVE-2025-39682 is actively exploited via Linux kTLS. If your servers face the internet, Sept. 21 isn’t a patch deadline—it’s a countdown clock. https://t.co/LERFtoTFrP #LinuxSecurity #CisaKev #KernelTls #Cve202539682 https://t.co/mdfWFbumkC

    @windowsforum

    18 Sept 2026

    56 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  24. Linux Kernel TLS CVE-2025-39682 added to CISA KEV today. Improper check for unusual or exceptional conditions. CISA cites active exploitation. Roll vendor kernel updates across managed fleets. Prioritize hosts using kernel TLS. #CVE #KEV

    @HoustonIntrove1

    18 Sept 2026

    44 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  25. 🚨 CVE-2025-39682 — CRITICAL — actively exploited per CISA KEV Linux Kernel CVSS 9.8 | EPSS 1% #Linux #CVE https://t.co/i4NRtIZsZW

    @threatpodium

    18 Sept 2026

    5 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  26. 🚨 CISA ADDS LINUX KERNEL TLS CVE-2025-39682 TO KEV CISA has added CVE-2025-39682 (Linux Kernel TLS) to its Known Exploited Vulnerabilities Catalog (2026-09-18; catalog count noted at 1716) based on evidence of active exploitation. Per CISA / technical notes: • Improper che

    @DailyDarkWeb

    18 Sept 2026

    5638 Impressions

    0 Retweets

    5 Likes

    1 Bookmark

    0 Replies

    0 Quotes

  27. 🛡️ We added Linux Kernel improper check for unusual or exceptional conditions vulnerability CVE-2025-39682 to our KEV Catalog. Visit https://t.co/myxOwap1Tf & apply mitigations to protect your org from cyberattacks. #Cybersecurity #InfoSec https://t.co/TAX5yszA2u

    @CISACyber

    18 Sept 2026

    6511 Impressions

    7 Retweets

    22 Likes

    4 Bookmarks

    3 Replies

    0 Quotes

  28. Critical #SUSE kernel patches released for CVE-2023-53676 (8.5), CVE-2025-39682 (7.0), and CVE-2025-40204 (8.7). Read more: 👉 https://t.co/0JRU7UQyiA #Security https://t.co/4FhU1EHYHH

    @Cezar_H_Linux

    22 Jan 2026

    60 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  29. CVE-2025-39682 In the Linux kernel, the following vulnerability has been resolved: tls: fix handling of zero-length records on the rx_list Each recvmsg() call must process either … https://t.co/OGtXRs6nyT

    @CVEnew

    6 Sept 2025

    383 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