ghsa-r9cc-7xcq-fpxg
Vulnerability from github
Published
2024-11-07 12:30
Modified
2024-11-13 18:31
Details

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

tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().

Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler().

""" We are seeing a use-after-free from a bpf prog attached to trace_tcp_retransmit_synack. The program passes the req->sk to the bpf_sk_storage_get_tracing kernel helper which does check for null before using it. """

The commit 83fccfc3940c ("inet: fix potential deadlock in reqsk_queue_unlink()") added timer_pending() in reqsk_queue_unlink() not to call del_timer_sync() from reqsk_timer_handler(), but it introduced a small race window.

Before the timer is called, expire_timers() calls detach_timer(timer, true) to clear timer->entry.pprev and marks it as not pending.

If reqsk_queue_unlink() checks timer_pending() just after expire_timers() calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires.

The reported UAF could happen if req->sk is close()d earlier than the timer expiration, which is 63s by default.

The scenario would be

  1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(), but del_timer_sync() is missed

  2. reqsk timer is executed and scheduled again

  3. req->sk is accept()ed and reqsk_put() decrements rsk_refcnt, but reqsk timer still has another one, and inet_csk_accept() does not clear req->sk for non-TFO sockets

  4. sk is close()d

  5. reqsk timer is executed again, and BPF touches req->sk

Let's not use timer_pending() by passing the caller context to __inet_csk_reqsk_queue_drop().

Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1]

[0] BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0

Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpf_sk_storage_get_tracing+0x2e/0x1b0 bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda bpf_trace_run2+0x4c/0xc0 tcp_rtx_synack+0xf9/0x100 reqsk_timer_handler+0xda/0x3d0 run_timer_softirq+0x292/0x8a0 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 intel_idle_irq+0x5a/0xa0 cpuidle_enter_state+0x94/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb

kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6

allocated by task 0 on cpu 9 at 260507.901592s: sk_prot_alloc+0x35/0x140 sk_clone_lock+0x1f/0x3f0 inet_csk_clone_lock+0x15/0x160 tcp_create_openreq_child+0x1f/0x410 tcp_v6_syn_recv_sock+0x1da/0x700 tcp_check_req+0x1fb/0x510 tcp_v6_rcv+0x98b/0x1420 ipv6_list_rcv+0x2258/0x26e0 napi_complete_done+0x5b1/0x2990 mlx5e_napi_poll+0x2ae/0x8d0 net_rx_action+0x13e/0x590 irq_exit_rcu+0xf5/0x320 common_interrupt+0x80/0x90 asm_common_interrupt+0x22/0x40 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb

freed by task 0 on cpu 9 at 260507.927527s: rcu_core_si+0x4ff/0xf10 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb

Show details on source website


{
  "affected": [],
  "aliases": [
    "CVE-2024-50154"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-07T10:15:06Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp/dccp: Don\u0027t use timer_pending() in reqsk_queue_unlink().\n\nMartin KaFai Lau reported use-after-free [0] in reqsk_timer_handler().\n\n  \"\"\"\n  We are seeing a use-after-free from a bpf prog attached to\n  trace_tcp_retransmit_synack. The program passes the req-\u003esk to the\n  bpf_sk_storage_get_tracing kernel helper which does check for null\n  before using it.\n  \"\"\"\n\nThe commit 83fccfc3940c (\"inet: fix potential deadlock in\nreqsk_queue_unlink()\") added timer_pending() in reqsk_queue_unlink() not\nto call del_timer_sync() from reqsk_timer_handler(), but it introduced a\nsmall race window.\n\nBefore the timer is called, expire_timers() calls detach_timer(timer, true)\nto clear timer-\u003eentry.pprev and marks it as not pending.\n\nIf reqsk_queue_unlink() checks timer_pending() just after expire_timers()\ncalls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will\ncontinue running and send multiple SYN+ACKs until it expires.\n\nThe reported UAF could happen if req-\u003esk is close()d earlier than the timer\nexpiration, which is 63s by default.\n\nThe scenario would be\n\n  1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(),\n     but del_timer_sync() is missed\n\n  2. reqsk timer is executed and scheduled again\n\n  3. req-\u003esk is accept()ed and reqsk_put() decrements rsk_refcnt, but\n     reqsk timer still has another one, and inet_csk_accept() does not\n     clear req-\u003esk for non-TFO sockets\n\n  4. sk is close()d\n\n  5. reqsk timer is executed again, and BPF touches req-\u003esk\n\nLet\u0027s not use timer_pending() by passing the caller context to\n__inet_csk_reqsk_queue_drop().\n\nNote that reqsk timer is pinned, so the issue does not happen in most\nuse cases. [1]\n\n[0]\nBUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0\n\nUse-after-free read at 0x00000000a891fb3a (in kfence-#1):\nbpf_sk_storage_get_tracing+0x2e/0x1b0\nbpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda\nbpf_trace_run2+0x4c/0xc0\ntcp_rtx_synack+0xf9/0x100\nreqsk_timer_handler+0xda/0x3d0\nrun_timer_softirq+0x292/0x8a0\nirq_exit_rcu+0xf5/0x320\nsysvec_apic_timer_interrupt+0x6d/0x80\nasm_sysvec_apic_timer_interrupt+0x16/0x20\nintel_idle_irq+0x5a/0xa0\ncpuidle_enter_state+0x94/0x273\ncpu_startup_entry+0x15e/0x260\nstart_secondary+0x8a/0x90\nsecondary_startup_64_no_verify+0xfa/0xfb\n\nkfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6\n\nallocated by task 0 on cpu 9 at 260507.901592s:\nsk_prot_alloc+0x35/0x140\nsk_clone_lock+0x1f/0x3f0\ninet_csk_clone_lock+0x15/0x160\ntcp_create_openreq_child+0x1f/0x410\ntcp_v6_syn_recv_sock+0x1da/0x700\ntcp_check_req+0x1fb/0x510\ntcp_v6_rcv+0x98b/0x1420\nipv6_list_rcv+0x2258/0x26e0\nnapi_complete_done+0x5b1/0x2990\nmlx5e_napi_poll+0x2ae/0x8d0\nnet_rx_action+0x13e/0x590\nirq_exit_rcu+0xf5/0x320\ncommon_interrupt+0x80/0x90\nasm_common_interrupt+0x22/0x40\ncpuidle_enter_state+0xfb/0x273\ncpu_startup_entry+0x15e/0x260\nstart_secondary+0x8a/0x90\nsecondary_startup_64_no_verify+0xfa/0xfb\n\nfreed by task 0 on cpu 9 at 260507.927527s:\nrcu_core_si+0x4ff/0xf10\nirq_exit_rcu+0xf5/0x320\nsysvec_apic_timer_interrupt+0x6d/0x80\nasm_sysvec_apic_timer_interrupt+0x16/0x20\ncpuidle_enter_state+0xfb/0x273\ncpu_startup_entry+0x15e/0x260\nstart_secondary+0x8a/0x90\nsecondary_startup_64_no_verify+0xfa/0xfb",
  "id": "GHSA-r9cc-7xcq-fpxg",
  "modified": "2024-11-13T18:31:52Z",
  "published": "2024-11-07T12:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50154"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5071beb59ee416e8ab456ac8647a4dabcda823b1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/51e34db64f4e43c7b055ccf881b7f3e0c31bb26d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8459d61fbf24967839a70235165673148c7c7f17"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/997ae8da14f1639ce6fb66a063dab54031cd61b3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e8c526f2bdf1845bedaf6a478816a3d06fa78b8f"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}


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.