fkie_cve-2025-39852
Vulnerability from fkie_nvd
Published
2025-09-19 16:15
Modified
2025-09-22 21:23
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: net/tcp: Fix socket memory leak in TCP-AO failure handling for IPv6 When tcp_ao_copy_all_matching() fails in tcp_v6_syn_recv_sock() it just exits the function. This ends up causing a memory-leak: unreferenced object 0xffff0000281a8200 (size 2496): comm "softirq", pid 0, jiffies 4295174684 hex dump (first 32 bytes): 7f 00 00 06 7f 00 00 06 00 00 00 00 cb a8 88 13 ................ 0a 00 03 61 00 00 00 00 00 00 00 00 00 00 00 00 ...a............ backtrace (crc 5ebdbe15): kmemleak_alloc+0x44/0xe0 kmem_cache_alloc_noprof+0x248/0x470 sk_prot_alloc+0x48/0x120 sk_clone_lock+0x38/0x3b0 inet_csk_clone_lock+0x34/0x150 tcp_create_openreq_child+0x3c/0x4a8 tcp_v6_syn_recv_sock+0x1c0/0x620 tcp_check_req+0x588/0x790 tcp_v6_rcv+0x5d0/0xc18 ip6_protocol_deliver_rcu+0x2d8/0x4c0 ip6_input_finish+0x74/0x148 ip6_input+0x50/0x118 ip6_sublist_rcv+0x2fc/0x3b0 ipv6_list_rcv+0x114/0x170 __netif_receive_skb_list_core+0x16c/0x200 netif_receive_skb_list_internal+0x1f0/0x2d0 This is because in tcp_v6_syn_recv_sock (and the IPv4 counterpart), when exiting upon error, inet_csk_prepare_forced_close() and tcp_done() need to be called. They make sure the newsk will end up being correctly free'd. tcp_v4_syn_recv_sock() makes this very clear by having the put_and_exit label that takes care of things. So, this patch here makes sure tcp_v4_syn_recv_sock and tcp_v6_syn_recv_sock have similar error-handling and thus fixes the leak for TCP-AO.
Impacted products
Vendor Product Version



{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/tcp: Fix socket memory leak in TCP-AO failure handling for IPv6\n\nWhen tcp_ao_copy_all_matching() fails in tcp_v6_syn_recv_sock() it just\nexits the function. This ends up causing a memory-leak:\n\nunreferenced object 0xffff0000281a8200 (size 2496):\n  comm \"softirq\", pid 0, jiffies 4295174684\n  hex dump (first 32 bytes):\n    7f 00 00 06 7f 00 00 06 00 00 00 00 cb a8 88 13  ................\n    0a 00 03 61 00 00 00 00 00 00 00 00 00 00 00 00  ...a............\n  backtrace (crc 5ebdbe15):\n    kmemleak_alloc+0x44/0xe0\n    kmem_cache_alloc_noprof+0x248/0x470\n    sk_prot_alloc+0x48/0x120\n    sk_clone_lock+0x38/0x3b0\n    inet_csk_clone_lock+0x34/0x150\n    tcp_create_openreq_child+0x3c/0x4a8\n    tcp_v6_syn_recv_sock+0x1c0/0x620\n    tcp_check_req+0x588/0x790\n    tcp_v6_rcv+0x5d0/0xc18\n    ip6_protocol_deliver_rcu+0x2d8/0x4c0\n    ip6_input_finish+0x74/0x148\n    ip6_input+0x50/0x118\n    ip6_sublist_rcv+0x2fc/0x3b0\n    ipv6_list_rcv+0x114/0x170\n    __netif_receive_skb_list_core+0x16c/0x200\n    netif_receive_skb_list_internal+0x1f0/0x2d0\n\nThis is because in tcp_v6_syn_recv_sock (and the IPv4 counterpart), when\nexiting upon error, inet_csk_prepare_forced_close() and tcp_done() need\nto be called. They make sure the newsk will end up being correctly\nfree\u0027d.\n\ntcp_v4_syn_recv_sock() makes this very clear by having the put_and_exit\nlabel that takes care of things. So, this patch here makes sure\ntcp_v4_syn_recv_sock and tcp_v6_syn_recv_sock have similar\nerror-handling and thus fixes the leak for TCP-AO."
    }
  ],
  "id": "CVE-2025-39852",
  "lastModified": "2025-09-22T21:23:01.543",
  "metrics": {},
  "published": "2025-09-19T16:15:44.090",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/3d2b356d994a8801acb397cafd28b13672c37ab5"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/46d33c878fc0b3d7570366b2c9912395b3f4e701"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/fa390321aba0a54d0f7ae95ee4ecde1358bb9234"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.


Loading…

Loading…