CVSS: 7.8EPSS: 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 • CWE-416: Use After Free •
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: 8EXPL: 0CVE-2022-49033 – btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit()
https://notcve.org/view.php?id=CVE-2022-49033
In the Linux kernel, the following vulnerability has been resolved: btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit() Syzkaller reported BUG as follows: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 Call Trace: <TASK> dump_stack_lvl+0xcd/0x134 __might_resched.cold+0x222/0x26b kmem_cache_alloc+0x2e7/0x3c0 update_qgroup_limit_item+0xe1/0x390 btrfs_qgroup_inherit+0x147b/0x1ee0 create_subvol+0x4eb/0x1710 btrfs_mksubvol+0xfe5/0x13f0 __btrfs_ioctl_snap_create+0x2b0/0x430 btrfs_ioctl_snap_create_v2+0x25a/0x520 btrfs_ioctl+0x2a1c/0x5ce0 __x64_sys_ioctl+0x193/0x200 do_syscall_64+0x35/0x80 Fix this by calling qgroup_dirty() on @dstqgroup, and update limit item in btrfs_run_qgroups() later outside of the spinlock context. • https://git.kernel.org/stable/c/89840b12c8fad7200eb6478525c13261512c01be https://git.kernel.org/stable/c/3c98e91be6aea4c7acf09da6eb0c107ea9186bb5 https://git.kernel.org/stable/c/f4b930a1602b05e77fee31f9616599b25e910a86 https://git.kernel.org/stable/c/8eb912af525042a7365295eb62f6d5270c2a6462 https://git.kernel.org/stable/c/01d7c41eac9129fba80d8aed0060caab4a7dbe09 https://git.kernel.org/stable/c/044da1a371a0da579e805e89c96865f62d8f6f69 https://git.kernel.org/stable/c/588ae4fdd8b11788a797776b10d6c44ae12bc133 https://git.kernel.org/stable/c/f7e942b5bb35d8e3af54053d19a6bf041 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-49032 – iio: health: afe4404: Fix oob read in afe4404_[read|write]_raw
https://notcve.org/view.php?id=CVE-2022-49032
In the Linux kernel, the following vulnerability has been resolved: iio: health: afe4404: Fix oob read in afe4404_[read|write]_raw KASAN report out-of-bounds read as follows: BUG: KASAN: global-out-of-bounds in afe4404_read_raw+0x2ce/0x380 Read of size 4 at addr ffffffffc00e4658 by task cat/278 Call Trace: afe4404_read_raw iio_read_channel_info dev_attr_show The buggy address belongs to the variable: afe4404_channel_leds+0x18/0xffffffffffffe9c0 This issue can be reproduce by singe command: $ cat /sys/bus/i2c/devices/0-0058/iio\:device0/in_intensity6_raw The array size of afe4404_channel_leds and afe4404_channel_offdacs are less than channels, so access with chan->address cause OOB read in afe4404_[read|write]_raw. Fix it by moving access before use them. • https://git.kernel.org/stable/c/b36e8257641a043764c62240316610c81e36376c https://git.kernel.org/stable/c/68de7da092f38395dde523f2e5db26eba6c23e28 https://git.kernel.org/stable/c/113c08030a89aaf406f8a1d4549d758a67c2afba https://git.kernel.org/stable/c/f5575041ec15310bdc50c42b8b22118cc900226e https://git.kernel.org/stable/c/3f566b626029ca8598d48e5074e56bb37399ca1b https://git.kernel.org/stable/c/5eb114f55b37dbc0487aa9c1913b81bb7837f1c4 https://git.kernel.org/stable/c/f7419fc42afc035f6b29ce713e17dcd2000c833f https://git.kernel.org/stable/c/d45d9f45e7b1365fd0d9bf14680d6d508 •