{"cve":"CVE-2023-52828","nvd":{"published":"2024-05-21T16:15:20.533","modified":"2026-06-17T06:43:40.570","status":"Analyzed","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Detect IP == ksym.end as part of BPF program\n\nNow that bpf_throw kfunc is the first such call instruction that has\nnoreturn semantics within the verifier, this also kicks in dead code\nelimination in unprecedented ways. For one, any instruction following\na bpf_throw call will never be marked as seen. Moreover, if a callchain\nends up throwing, any instructions after the call instruction to the\neventually throwing subprog in callers will also never be marked as\nseen.\n\nThe tempting way to fix this would be to emit extra 'int3' instructions\nwhich bump the jited_len of a program, and ensure that during runtime\nwhen a program throws, we can discover its boundaries even if the call\ninstruction to bpf_throw (or to subprogs that always throw) is emitted\nas the final instruction in the program.\n\nAn example of such a program would be this:\n\ndo_something():\n\t...\n\tr0 = 0\n\texit\n\nfoo():\n\tr1 = 0\n\tcall bpf_throw\n\tr0 = 0\n\texit\n\nbar(cond):\n\tif r1 != 0 goto pc+2\n\tcall do_something\n\texit\n\tcall foo\n\tr0 = 0  // Never seen by verifier\n\texit\t//\n\nmain(ctx):\n\tr1 = ...\n\tcall bar\n\tr0 = 0\n\texit\n\nHere, if we do end up throwing, the stacktrace would be the following:\n\nbpf_throw\nfoo\nbar\nmain\n\nIn bar, the final instruction emitted will be the call to foo, as such,\nthe return address will be the subsequent instruction (which the JIT\nemits as int3 on x86). This will end up lying outside the jited_len of\nthe program, thus, when unwinding, we will fail to discover the return\naddress as belonging to any program and end up in a panic due to the\nunreliable stack unwinding of BPF programs that we never expect.\n\nTo remedy this case, make bpf_prog_ksym_find treat IP == ksym.end as\npart of the BPF program, so that is_bpf_text_address returns true when\nsuch a case occurs, and we are able to unwind reliably when the final\ninstruction ends up being a call instruction.","cvss_v4":null,"cvss_v3":{"version":"3.1","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","score":5.5},"cwes":[],"references":["https://git.kernel.org/stable/c/327b92e8cb527ae097961ffd1610c720481947f5","https://git.kernel.org/stable/c/6058e4829696412457729a00734969acc6fd1d18","https://git.kernel.org/stable/c/66d9111f3517f85ef2af0337ece02683ce0faf21","https://git.kernel.org/stable/c/821a7e4143af115b840ec199eb179537e18af922","https://git.kernel.org/stable/c/aa42a7cb92647786719fe9608685da345883878f"],"products":["linux:linux_kernel"],"source":"nvd","synced_at":"2026-10-19T21:50:30.954589733+00:00"},"epss":{"cve":"CVE-2023-52828","score":0.00246,"percentile":0.15953,"date":"2026-10-31"},"kev":null,"osv":[],"attribution":["This product uses the NVD API but is not endorsed or certified by the NVD.","EPSS scores: FIRST Exploit Prediction Scoring System, https://www.first.org/epss","Known exploited vulnerabilities: CISA Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog","Package advisories: OSV (https://osv.dev), from the GitHub Advisory Database, PyPA, Go, RustSec and other ecosystem databases, under CC-BY 4.0 or CC0","CVE records: the CVE Program's CVE List (https://www.cve.org), under its terms of use (https://www.cve.org/Legal/TermsOfUse). CVE is a registered trademark of The MITRE Corporation; this product is not affiliated with the CVE Program."]}