[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"repo-stars":3,"vuln-DEBIAN-CVE-2024-50154":6},{"stargazers_count":4,"fetched_at":5},7,"2026-06-04T20:55:29.923Z",{"id":7,"descriptions":8,"cisa":9,"weaknesses":10,"exploits":11,"aliases":12,"duplicate_of":9,"upstream":13,"downstream":16,"duplicates":21,"related":22,"reserved_at":9,"published_at":23,"modified_at":24,"state":9,"summary":25,"references_raw":27,"kevs":34,"epss":9,"epss_history":35,"metrics":36,"affected":42},"DEBIAN-CVE-2024-50154","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",null,[],[],[],[14],{"_key":15},"CVE-2024-50154",[17,19],{"_key":18},"DLA-4008-1",{"_key":20},"DLA-4178-1",[],[],"2024-11-07T10:15:06.987Z","2026-04-28T20:28:51.852141Z",{"cisa_kev":26,"cisa_ransomware":26,"cisa_vendor":9,"epss_severity":9,"epss_score":9,"severity":9,"severity_score":9,"severity_version":9,"severity_source":9,"severity_vector":9,"severity_status":9},false,[28],{"url":29,"sources":30,"tags":32},"https://security-tracker.debian.org/tracker/CVE-2024-50154",[31],"osv_debian",[33],"Advisory",[],[],[37],{"source":31,"cvss_v2_0":9,"cvss_v3_0":9,"cvss_v3_1":38,"cvss_v4_0":9},{"baseScore":4,"baseSeverity":9,"vectorString":39,"impactScore":40,"exploitabilityScore":41},"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",9.8,2.6,[43,62],{"ecosystem":44,"name":45,"vendor":46,"product":45,"cpe_part":9,"purl_type":47,"purl_namespace":46,"purl_name":45,"source":9,"versions":48},"Debian","linux","debian","deb",[49,55,58,61],{"version":50,"is_range":51,"range_type":52,"version_start":9,"version_start_type":9,"version_end":53,"version_end_type":54,"fixed_in":9},"lt5_10_237_1",true,"ecosystem","5.10.237-1","excluding",{"version":56,"is_range":51,"range_type":52,"version_start":9,"version_start_type":9,"version_end":57,"version_end_type":54,"fixed_in":9},"lt6_1_115_1","6.1.115-1",{"version":59,"is_range":51,"range_type":52,"version_start":9,"version_start_type":9,"version_end":60,"version_end_type":54,"fixed_in":9},"lt6_11_6_1","6.11.6-1",{"version":59,"is_range":51,"range_type":52,"version_start":9,"version_start_type":9,"version_end":60,"version_end_type":54,"fixed_in":9},{"ecosystem":44,"name":63,"vendor":46,"product":63,"cpe_part":9,"purl_type":47,"purl_namespace":46,"purl_name":63,"source":9,"versions":64},"linux-6.1",[65],{"version":66,"is_range":51,"range_type":52,"version_start":9,"version_start_type":9,"version_end":67,"version_end_type":54,"fixed_in":9},"lt6_1_119_1~deb11u1","6.1.119-1~deb11u1"]