{ "document": { "category": "csaf_base", "csaf_version": "2.0", "distribution": { "tlp": { "label": "WHITE" } }, "lang": "en", "notes": [ { "category": "legal_disclaimer", "text": "The Netherlands Cyber Security Center (henceforth: NCSC-NL) maintains this portal to enhance access to its information and vulnerabilities. The use of this information is subject to the following terms and conditions:\n\nThe vulnerabilities disclosed in this portal are gathered by NCSC-NL from a variety of open sources, which the user can retrieve from other platforms. NCSC-NL makes every reasonable effort to ensure that the content of this portal is kept up to date, and that it is accurate and complete. Nevertheless, NCSC-NL cannot entirely rule out the possibility of errors, and therefore cannot give any warranty in respect of its completeness, accuracy or real-time keeping up-to-date. NCSC-NL does not control nor guarantee the accuracy, relevance, timeliness or completeness of information obtained from these external sources. The vulnerabilities disclosed in this portal are intended solely for the convenience of professional parties to take appropriate measures to manage the risks posed to the cybersecurity. No rights can be derived from the information provided therein.\n\nNCSC-NL and the Kingdom of the Netherlands assume no legal liability or responsibility for any damage resulting from either the use or inability of use of the vulnerabilities disclosed in this portal. This includes damage resulting from the inaccuracy of incompleteness of the information contained in it.\nThe information on this page is subject to Dutch law. All disputes related to or arising from the use of this portal regarding the disclosure of vulnerabilities will be submitted to the competent court in The Hague. This choice of means also applies to the court in summary proceedings." } ], "publisher": { "category": "coordinator", "contact_details": "cert@ncsc.nl", "name": "National Cyber Security Centre", "namespace": "https://www.ncsc.nl/" }, "title": "CVE-2026-23450", "tracking": { "current_release_date": "2026-04-03T16:52:29.194097Z", "generator": { "date": "2026-02-17T15:00:00Z", "engine": { "name": "V.E.L.M.A", "version": "1.7" } }, "id": "CVE-2026-23450", "initial_release_date": "2026-04-03T15:40:24.019664Z", "revision_history": [ { "date": "2026-04-03T15:40:24.019664Z", "number": "1", "summary": "CVE created.| Source created.| CVE status created. (valid)| Description created for source.| Products created (7).| Products connected (8).| References created (6)." }, { "date": "2026-04-03T15:40:37.520678Z", "number": "2", "summary": "NCSC Score created." }, { "date": "2026-04-03T16:48:51.201419Z", "number": "3", "summary": "Source created.| CVE status created. (valid)| Description created for source.| References created (6)." } ], "status": "interim", "version": "3" } }, "product_tree": { "branches": [ { "branches": [ { "branches": [ { "category": "product_version_range", "name": "vers:git/8270d9c21041470f58348248b9d9dcf3bf79592e|<1e4f873879e075bbd4eb1c644d6933303ac5eba4", "product": { "name": "vers:git/8270d9c21041470f58348248b9d9dcf3bf79592e|<1e4f873879e075bbd4eb1c644d6933303ac5eba4", "product_id": "CSAFPID-5992353" } }, { "category": "product_version_range", "name": "vers:git/8270d9c21041470f58348248b9d9dcf3bf79592e|<1fab5ece76fb42a761178dcd0ebcbf578377b0dd", "product": { "name": "vers:git/8270d9c21041470f58348248b9d9dcf3bf79592e|<1fab5ece76fb42a761178dcd0ebcbf578377b0dd", "product_id": "CSAFPID-5992357" } }, { "category": "product_version_range", "name": "vers:git/8270d9c21041470f58348248b9d9dcf3bf79592e|<6d5e4538364b9ceb1ac2941a4deb86650afb3538", "product": { "name": "vers:git/8270d9c21041470f58348248b9d9dcf3bf79592e|<6d5e4538364b9ceb1ac2941a4deb86650afb3538", "product_id": "CSAFPID-5992358" } }, { "category": "product_version_range", "name": "vers:git/8270d9c21041470f58348248b9d9dcf3bf79592e|syn_recv_sock on the clcsock (TCP\nlistening socket). It reads sk_user_data to get the smc_sock\npointer. However, when the SMC listen socket is being closed\nconcurrently, smc_close_active() sets clcsock->sk_user_data\nto NULL under sk_callback_lock, and then the smc_sock itself\ncan be freed via sock_put() in smc_release().\n\nThis leads to two issues:\n\n1) NULL pointer dereference: sk_user_data is NULL when\n accessed.\n2) Use-after-free: sk_user_data is read as non-NULL, but the\n smc_sock is freed before its fields (e.g., queued_smc_hs,\n ori_af_ops) are accessed.\n\nThe race window looks like this (the syzkaller crash [1]\ntriggers via the SYN cookie path: tcp_get_cookie_sock() ->\nsmc_tcp_syn_recv_sock(), but the normal tcp_check_req() path\nhas the same race):\n\n CPU A (softirq) CPU B (process ctx)\n\n tcp_v4_rcv()\n TCP_NEW_SYN_RECV:\n sk = req->rsk_listener\n sock_hold(sk)\n /* No lock on listener */\n smc_close_active():\n write_lock_bh(cb_lock)\n sk_user_data = NULL\n write_unlock_bh(cb_lock)\n ...\n smc_clcsock_release()\n sock_put(smc->sk) x2\n -> smc_sock freed!\n tcp_check_req()\n smc_tcp_syn_recv_sock():\n smc = user_data(sk)\n -> NULL or dangling\n smc->queued_smc_hs\n -> crash!\n\nNote that the clcsock and smc_sock are two independent objects\nwith separate refcounts. TCP stack holds a reference on the\nclcsock, which keeps it alive, but this does NOT prevent the\nsmc_sock from being freed.\n\nFix this by using RCU and refcount_inc_not_zero() to safely\naccess smc_sock. Since smc_tcp_syn_recv_sock() is called in\nthe TCP three-way handshake path, taking read_lock_bh on\nsk_callback_lock is too heavy and would not survive a SYN\nflood attack. Using rcu_read_lock() is much more lightweight.\n\n- Set SOCK_RCU_FREE on the SMC listen socket so that\n smc_sock freeing is deferred until after the RCU grace\n period. This guarantees the memory is still valid when\n accessed inside rcu_read_lock().\n- Use rcu_read_lock() to protect reading sk_user_data.\n- Use refcount_inc_not_zero(&smc->sk.sk_refcnt) to pin the\n smc_sock. If the refcount has already reached zero (close\n path completed), it returns false and we bail out safely.\n\nNote: smc_hs_congested() has a similar lockless read of\nsk_user_data without rcu_read_lock(), but it only checks for\nNULL and accesses the global smc_hs_wq, never dereferencing\nany smc_sock field, so it is not affected.\n\nReproducer was verified with mdelay injection and smc_run,\nthe issue no longer occurs with this patch applied.\n\n[1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9", "title": "cveprojectv5 - https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/23xxx/CVE-2026-23450.json" }, { "category": "description", "text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock()\n\nSyzkaller reported a panic in smc_tcp_syn_recv_sock() [1].\n\nsmc_tcp_syn_recv_sock() is called in the TCP receive path\n(softirq) via icsk_af_ops->syn_recv_sock on the clcsock (TCP\nlistening socket). It reads sk_user_data to get the smc_sock\npointer. However, when the SMC listen socket is being closed\nconcurrently, smc_close_active() sets clcsock->sk_user_data\nto NULL under sk_callback_lock, and then the smc_sock itself\ncan be freed via sock_put() in smc_release().\n\nThis leads to two issues:\n\n1) NULL pointer dereference: sk_user_data is NULL when\n accessed.\n2) Use-after-free: sk_user_data is read as non-NULL, but the\n smc_sock is freed before its fields (e.g., queued_smc_hs,\n ori_af_ops) are accessed.\n\nThe race window looks like this (the syzkaller crash [1]\ntriggers via the SYN cookie path: tcp_get_cookie_sock() ->\nsmc_tcp_syn_recv_sock(), but the normal tcp_check_req() path\nhas the same race):\n\n CPU A (softirq) CPU B (process ctx)\n\n tcp_v4_rcv()\n TCP_NEW_SYN_RECV:\n sk = req->rsk_listener\n sock_hold(sk)\n /* No lock on listener */\n smc_close_active():\n write_lock_bh(cb_lock)\n sk_user_data = NULL\n write_unlock_bh(cb_lock)\n ...\n smc_clcsock_release()\n sock_put(smc->sk) x2\n -> smc_sock freed!\n tcp_check_req()\n smc_tcp_syn_recv_sock():\n smc = user_data(sk)\n -> NULL or dangling\n smc->queued_smc_hs\n -> crash!\n\nNote that the clcsock and smc_sock are two independent objects\nwith separate refcounts. TCP stack holds a reference on the\nclcsock, which keeps it alive, but this does NOT prevent the\nsmc_sock from being freed.\n\nFix this by using RCU and refcount_inc_not_zero() to safely\naccess smc_sock. Since smc_tcp_syn_recv_sock() is called in\nthe TCP three-way handshake path, taking read_lock_bh on\nsk_callback_lock is too heavy and would not survive a SYN\nflood attack. Using rcu_read_lock() is much more lightweight.\n\n- Set SOCK_RCU_FREE on the SMC listen socket so that\n smc_sock freeing is deferred until after the RCU grace\n period. This guarantees the memory is still valid when\n accessed inside rcu_read_lock().\n- Use rcu_read_lock() to protect reading sk_user_data.\n- Use refcount_inc_not_zero(&smc->sk.sk_refcnt) to pin the\n smc_sock. If the refcount has already reached zero (close\n path completed), it returns false and we bail out safely.\n\nNote: smc_hs_congested() has a similar lockless read of\nsk_user_data without rcu_read_lock(), but it only checks for\nNULL and accesses the global smc_hs_wq, never dereferencing\nany smc_sock field, so it is not affected.\n\nReproducer was verified with mdelay injection and smc_run,\nthe issue no longer occurs with this patch applied.\n\n[1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9", "title": "nvd - https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-23450" }, { "category": "other", "text": "4.1", "title": "NCSC Score" }, { "category": "other", "text": "The value of the most recent CVSS (V3) score, Is related to a product by vendor Linux", "title": "NCSC Score top decreasing factors" } ], "product_status": { "known_affected": [ "CSAFPID-1335298", "CSAFPID-5992353", "CSAFPID-5992354", "CSAFPID-5992355", "CSAFPID-5992356", "CSAFPID-5992357", "CSAFPID-5992358", "CSAFPID-5992359" ], "known_not_affected": [ "CSAFPID-1335299", "CSAFPID-5904647", "CSAFPID-5904654", "CSAFPID-5904671", "CSAFPID-5905005", "CSAFPID-5905006", "CSAFPID-5905027" ] }, "references": [ { "category": "external", "summary": "Source - cveprojectv5", "url": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/23xxx/CVE-2026-23450.json" }, { "category": "external", "summary": "Source - nvd", "url": "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-23450" }, { "category": "external", "summary": "Reference - cveprojectv5; nvd", "url": "https://git.kernel.org/stable/c/1e4f873879e075bbd4eb1c644d6933303ac5eba4" }, { "category": "external", "summary": "Reference - cveprojectv5; nvd", "url": "https://git.kernel.org/stable/c/f00fc26c8a06442b225a350fe000c0a11483e6a3" }, { "category": "external", "summary": "Reference - cveprojectv5; nvd", "url": "https://git.kernel.org/stable/c/cadf3da46c15523fba90d80c9955f536ee3b4023" }, { "category": "external", "summary": "Reference - cveprojectv5; nvd", "url": "https://git.kernel.org/stable/c/fd7579f0a2c84ba8a7d4f206201b50dc8ddf90c2" }, { "category": "external", "summary": "Reference - cveprojectv5; nvd", "url": "https://git.kernel.org/stable/c/1fab5ece76fb42a761178dcd0ebcbf578377b0dd" }, { "category": "external", "summary": "Reference - cveprojectv5; nvd", "url": "https://git.kernel.org/stable/c/6d5e4538364b9ceb1ac2941a4deb86650afb3538" } ], "title": "CVE-2026-23450" } ] }