CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50072 – x86/bugs: Use code segment selector for VERW operand
https://notcve.org/view.php?id=CVE-2024-50072
In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Use code segment selector for VERW operand Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call: general protection fault: 0000 [#1] PREEMPT SMP CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1 Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010 EIP: restore_all_switch_stack+0xbe/0xcf EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046 CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0 Call Trace: show_regs+0x70/0x78 die_addr+0x29/0x70 exc_general_protection+0x13c/0x348 exc_bounds+0x98/0x98 handle_exception+0x14d/0x14d exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction: #GP(0) - If a memory operand effective address is outside the CS, DS, ES, FS, or GS segment limit. CLEAR_CPU_BUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. • https://git.kernel.org/stable/c/50f021f0b985629accf10481a6e89af8b9700583 https://git.kernel.org/stable/c/d54de9f2a127090f2017184e8257795b487d5312 https://git.kernel.org/stable/c/2e3087505ddb8ba2d3d4c81306cca11e868fcdb9 https://git.kernel.org/stable/c/ca13d8cd8dac25558da4ee8df4dc70e8e7f9d762 https://git.kernel.org/stable/c/a0e2dab44d22b913b4c228c8b52b2a104434b0b3 https://git.kernel.org/stable/c/51eca9f1fd047b500137d021f882d93f03280118 https://git.kernel.org/stable/c/bfd1d223d80cb29a210caa1bd5e21f0816d58f02 https://git.kernel.org/stable/c/ada431c6c31a2c8c37991c46089af5caa •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50067 – uprobe: avoid out-of-bounds memory access of fetching args
https://notcve.org/view.php?id=CVE-2024-50067
In the Linux kernel, the following vulnerability has been resolved: uprobe: avoid out-of-bounds memory access of fetching args Uprobe needs to fetch args into a percpu buffer, and then copy to ring buffer to avoid non-atomic context problem. Sometimes user-space strings, arrays can be very large, but the size of percpu buffer is only page size. And store_trace_args() won't check whether these data exceeds a single page or not, caused out-of-bounds memory access. It could be reproduced by following steps: 1. build kernel with CONFIG_KASAN enabled 2. save follow program as test.c ``` \#include <stdio.h> \#include <stdlib.h> \#include <string.h> // If string length large than MAX_STRING_SIZE, the fetch_store_strlen() // will return 0, cause __get_data_size() return shorter size, and // store_trace_args() will not trigger out-of-bounds access. // So make string length less than 4096. \#define STRLEN 4093 void generate_string(char *str, int n) { int i; for (i = 0; i < n; ++i) { char c = i % 26 + 'a'; str[i] = c; } str[n-1] = '\0'; } void print_string(char *str) { printf("%s\n", str); } int main() { char tmp[STRLEN]; generate_string(tmp, STRLEN); print_string(tmp); return 0; } ``` 3. compile program `gcc -o test test.c` 4. get the offset of `print_string()` ``` objdump -t test | grep -w print_string 0000000000401199 g F .text 000000000000001b print_string ``` 5. configure uprobe with offset 0x1199 ``` off=0x1199 cd /sys/kernel/debug/tracing/ echo "p /root/test:${off} arg1=+0(%di):ustring arg2=\$comm arg3=+0(%di):ustring" > uprobe_events echo 1 > events/uprobes/enable echo 1 > tracing_on ``` 6. run `test`, and kasan will report error. ================================================================== BUG: KASAN: use-after-free in strncpy_from_user+0x1d6/0x1f0 Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18 Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x55/0x70 print_address_description.constprop.0+0x27/0x310 kasan_report+0x10f/0x120 ? strncpy_from_user+0x1d6/0x1f0 strncpy_from_user+0x1d6/0x1f0 ? rmqueue.constprop.0+0x70d/0x2ad0 process_fetch_insn+0xb26/0x1470 ? __pfx_process_fetch_insn+0x10/0x10 ? • https://git.kernel.org/stable/c/dcad1a204f72624796ae83359403898d10393b9c https://git.kernel.org/stable/c/0dc3ad9ad2188da7f090b3dbe4d2fcd9ae8ae64f https://git.kernel.org/stable/c/9e5f93788c9dd4309e75a56860a1ac44a8e117b9 https://git.kernel.org/stable/c/537ad4a431f6dddbf15d40d19f24bb9ee12b55cb https://git.kernel.org/stable/c/373b9338c9722a368925d83bc622c596896b328e •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52919 – nfc: nci: fix possible NULL pointer dereference in send_acknowledge()
https://notcve.org/view.php?id=CVE-2023-52919
In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix possible NULL pointer dereference in send_acknowledge() Handle memory allocation failure from nci_skb_alloc() (calling alloc_skb()) to avoid possible NULL pointer dereference. • https://git.kernel.org/stable/c/391d8a2da787257aeaf952c974405b53926e3fb3 https://git.kernel.org/stable/c/2b2edf089df3a69f0072c6e71563394c5a94e62e https://git.kernel.org/stable/c/5622592f8f74ae3e594379af02e64ea84772d0dd https://git.kernel.org/stable/c/76050b0cc5a72e0c7493287b7e18e1cb9e3c4612 https://git.kernel.org/stable/c/c95fa5b20fe03609e0894656fa43c18045b5097e https://git.kernel.org/stable/c/ffdc881f68073ff86bf21afb9bb954812e8278be https://git.kernel.org/stable/c/d7dbdbe3800a908eecd4975c31be47dd45e2104a https://git.kernel.org/stable/c/bb6cacc439ddd2cd51227ab193f4f91cf •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52918 – media: pci: cx23885: check cx23885_vdev_init() return
https://notcve.org/view.php?id=CVE-2023-52918
In the Linux kernel, the following vulnerability has been resolved: media: pci: cx23885: check cx23885_vdev_init() return cx23885_vdev_init() can return a NULL pointer, but that pointer is used in the next line without a check. Add a NULL pointer check and go to the error unwind if it is NULL. • https://git.kernel.org/stable/c/8e31b096e2e1949bc8f0be019c9ae70d414404c6 https://git.kernel.org/stable/c/199a42fc4c45e8b7f19efeb15dbc36889a599ac2 https://git.kernel.org/stable/c/e7385510e2550a9f8b6f3d5f33c5b894ab9ba976 https://git.kernel.org/stable/c/a5f1d30c51c485cec7a7de60205667c3ff86c303 https://git.kernel.org/stable/c/06ee04a907d64ee3910fecedd05d7f1be4b1b70e https://git.kernel.org/stable/c/b1397fb4a779fca560c43d2acf6702d41b4a495b https://git.kernel.org/stable/c/15126b916e39b0cb67026b0af3c014bfeb1f76b3 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50063 – bpf: Prevent tail call between progs attached to different hooks
https://notcve.org/view.php?id=CVE-2024-50063
In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent tail call between progs attached to different hooks bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed. For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2's prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed. Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. • https://git.kernel.org/stable/c/f1b9509c2fb0ef4db8d22dac9aef8e856a5d81f6 https://git.kernel.org/stable/c/5d5e3b4cbe8ee16b7bf96fd73a421c92a9da3ca1 https://git.kernel.org/stable/c/88c2a10e6c176c2860cd0659f4c0e9d20b3f64d1 https://git.kernel.org/stable/c/28ead3eaabc16ecc907cfb71876da028080f6356 •