Bugzilla – Bug 1224943
VUL-0: REJECTED: CVE-2023-52793: kernel: samples/bpf: syscall_tp_user: Fix array out-of-bound access
Last modified: 2024-05-24 14:52:14 UTC
In the Linux kernel, the following vulnerability has been resolved: samples/bpf: syscall_tp_user: Fix array out-of-bound access Commit 06744f24696e ("samples/bpf: Add openat2() enter/exit tracepoint to syscall_tp sample") added two more eBPF programs to support the openat2() syscall. However, it did not increase the size of the array that holds the corresponding bpf_links. This leads to an out-of-bound access on that array in the bpf_object__for_each_program loop and could corrupt other variables on the stack. On our testing QEMU, it corrupts the map1_fds array and causes the sample to fail: # ./syscall_tp prog #0: map ids 4 5 verify map:4 val: 5 map_lookup failed: Bad file descriptor Dynamically allocate the array based on the number of programs reported by libbpf to prevent similar inconsistencies in the future References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-52793 https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2023/CVE-2023-52793.mbox https://git.kernel.org/stable/c/61576b7a0f28f924da06bead92a39a6d9aa2404a https://git.kernel.org/stable/c/de4825a444560f8cb78b03dda3ba873fab88bc4f https://git.kernel.org/stable/c/9220c3ef6fefbf18f24aeedb1142a642b3de0596 https://www.cve.org/CVERecord?id=CVE-2023-52793
Shung-Hsi Yu, I am not familiar with BPF much but does it make sense to apply CVE to something in a samples/bpf? Should we dispute this?
Agree that this should be disputed. I don't think it make sense to apply CVE in samples/bpf.
Dispute sent to LKML https://lore.kernel.org/all/7p643u2dcn6cen32dbtrcki62qrn3o2hyiplbx2hkpcojuiev5@3hbnkswhtha3/ (On a side note: I used to CVE-2023-52793.mbox in vulns.git to reply, which seems to not contain the original Message-ID field and hence my reply did not have the correct In-Reply-To and References field)
This CVE has been rejected https://lore.kernel.org/all/2024052404-founding-motion-5e89@gregkh/
(In reply to Shung-Hsi Yu from comment #3) > Dispute sent to LKML > https://lore.kernel.org/all/ > 7p643u2dcn6cen32dbtrcki62qrn3o2hyiplbx2hkpcojuiev5@3hbnkswhtha3/ Thanks! > (On a side note: I used to CVE-2023-52793.mbox in vulns.git to reply, which > seems to not contain the original Message-ID field and hence my reply did > not have the correct In-Reply-To and References field) I have never used the mbox file and it seems reasonable to send them a feature request to contain the msg-id as well. So far I have used https://lore.kernel.org/linux-cve-announce/?q=CVE-XXXX-YYYYY opened the found link and used b4 mbox msg-id to get the original email. Quite clumsy but reliable.
nothing to be done. Can be closed as INVALID
Closing as CVE was rejected, thanks all.