ghsa-r22j-fw7c-mp4g
Vulnerability from github
Published
2025-05-02 18:31
Modified
2025-05-02 18:31
Details

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

mptcp: use the workqueue to destroy unaccepted sockets

Christoph reported a UaF at token lookup time after having refactored the passive socket initialization part:

BUG: KASAN: use-after-free in __token_bucket_busy+0x253/0x260 Read of size 4 at addr ffff88810698d5b0 by task syz-executor653/3198

CPU: 1 PID: 3198 Comm: syz-executor653 Not tainted 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x6e/0x91 print_report+0x16a/0x46f kasan_report+0xad/0x130 __token_bucket_busy+0x253/0x260 mptcp_token_new_connect+0x13d/0x490 mptcp_connect+0x4ed/0x860 __inet_stream_connect+0x80e/0xd90 tcp_sendmsg_fastopen+0x3ce/0x710 mptcp_sendmsg+0xff1/0x1a20 inet_sendmsg+0x11d/0x140 __sys_sendto+0x405/0x490 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc

We need to properly clean-up all the paired MPTCP-level resources and be sure to release the msk last, even when the unaccepted subflow is destroyed by the TCP internals via inet_child_forget().

We can re-use the existing MPTCP_WORK_CLOSE_SUBFLOW infra, explicitly checking that for the critical scenario: the closed subflow is the MPC one, the msk is not accepted and eventually going through full cleanup.

With such change, __mptcp_destroy_sock() is always called on msk sockets, even on accepted ones. We don't need anymore to transiently drop one sk reference at msk clone time.

Please note this commit depends on the parent one:

mptcp: refactor passive socket initialization

Show details on source website


{
  "affected": [],
  "aliases": [
    "CVE-2023-53072"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-02T16:15:26Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: use the workqueue to destroy unaccepted sockets\n\nChristoph reported a UaF at token lookup time after having\nrefactored the passive socket initialization part:\n\n  BUG: KASAN: use-after-free in __token_bucket_busy+0x253/0x260\n  Read of size 4 at addr ffff88810698d5b0 by task syz-executor653/3198\n\n  CPU: 1 PID: 3198 Comm: syz-executor653 Not tainted 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n  Call Trace:\n   \u003cTASK\u003e\n   dump_stack_lvl+0x6e/0x91\n   print_report+0x16a/0x46f\n   kasan_report+0xad/0x130\n   __token_bucket_busy+0x253/0x260\n   mptcp_token_new_connect+0x13d/0x490\n   mptcp_connect+0x4ed/0x860\n   __inet_stream_connect+0x80e/0xd90\n   tcp_sendmsg_fastopen+0x3ce/0x710\n   mptcp_sendmsg+0xff1/0x1a20\n   inet_sendmsg+0x11d/0x140\n   __sys_sendto+0x405/0x490\n   __x64_sys_sendto+0xdc/0x1b0\n   do_syscall_64+0x3b/0x90\n   entry_SYSCALL_64_after_hwframe+0x72/0xdc\n\nWe need to properly clean-up all the paired MPTCP-level\nresources and be sure to release the msk last, even when\nthe unaccepted subflow is destroyed by the TCP internals\nvia inet_child_forget().\n\nWe can re-use the existing MPTCP_WORK_CLOSE_SUBFLOW infra,\nexplicitly checking that for the critical scenario: the\nclosed subflow is the MPC one, the msk is not accepted and\neventually going through full cleanup.\n\nWith such change, __mptcp_destroy_sock() is always called\non msk sockets, even on accepted ones. We don\u0027t need anymore\nto transiently drop one sk reference at msk clone time.\n\nPlease note this commit depends on the parent one:\n\n  mptcp: refactor passive socket initialization",
  "id": "GHSA-r22j-fw7c-mp4g",
  "modified": "2025-05-02T18:31:34Z",
  "published": "2025-05-02T18:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53072"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2827f099b3fb9a59263c997400e9182f5d423e84"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/804cf487fb0031f3c74755b78d8663333f0ba636"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b6985b9b82954caa53f862d6059d06c0526254f0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


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.
  • 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…