CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48950 – perf: Fix perf_pending_task() UaF
https://notcve.org/view.php?id=CVE-2022-48950
In the Linux kernel, the following vulnerability has been resolved: perf: Fix perf_pending_task() UaF Per syzbot it is possible for perf_pending_task() to run after the event is free()'d. There are two related but distinct cases: - the task_work was already queued before destroying the event; - destroying the event itself queues the task_work. The first cannot be solved using task_work_cancel() since perf_release() itself might be called from a task_work (____fput), which means the current->task_works list is already empty and task_work_cancel() won't be able to find the perf_pending_task() entry. The simplest alternative is extending the perf_event lifetime to cover the task_work. The second is just silly, queueing a task_work while you know the event is going away makes no sense and is easily avoided by re-arranging how the event is marked STATE_DEAD and ensuring it goes through STATE_OFF on the way down. • https://git.kernel.org/stable/c/8bffa95ac19ff27c8261904f89d36c7fcf215d59 https://git.kernel.org/stable/c/78e1317a174edbfd1182599bf76c092a2877672c https://git.kernel.org/stable/c/517e6a301f34613bff24a8e35b5455884f2d83d8 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2022-48948 – usb: gadget: uvc: Prevent buffer overflow in setup handler
https://notcve.org/view.php?id=CVE-2022-48948
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Prevent buffer overflow in setup handler Setup function uvc_function_setup permits control transfer requests with up to 64 bytes of payload (UVC_MAX_REQUEST_SIZE), data stage handler for OUT transfer uses memcpy to copy req->actual bytes to uvc_event->data.data array of size 60. This may result in an overflow of 4 bytes. • https://git.kernel.org/stable/c/cdda479f15cd13fa50a913ca85129c0437cc7b91 https://git.kernel.org/stable/c/4972e3528b968665b596b5434764ff8fd9446d35 https://git.kernel.org/stable/c/06fd17ee92c8f1704c7e54ec0fd50ae0542a49a5 https://git.kernel.org/stable/c/bc8380fe5768c564f921f7b4eaba932e330b9e4b https://git.kernel.org/stable/c/b8fb1cba934ea122b50f13a4f9d6fc4fdc43d2be https://git.kernel.org/stable/c/c79538f32df12887f110dcd6b9c825b482905f24 https://git.kernel.org/stable/c/6b41a35b41f77821db24f2d8f66794b390a585c5 https://git.kernel.org/stable/c/7b1f773277a72f9756d47a41b94e43506 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48947 – Bluetooth: L2CAP: Fix u8 overflow
https://notcve.org/view.php?id=CVE-2022-48947
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix u8 overflow By keep sending L2CAP_CONF_REQ packets, chan->num_conf_rsp increases multiple times and eventually it will wrap around the maximum number (i.e., 255). This patch prevents this by adding a boundary check with L2CAP_MAX_CONF_RSP Btmon log: Bluetooth monitor ver 5.64 = Note: Linux version 6.1.0-rc2 (x86_64) 0.264594 = Note: Bluetooth subsystem version 2.22 0.264636 @ MGMT Open: btmon (privileged) version 1.22 {0x0001} 0.272191 = New Index: 00:00:00:00:00:00 (Primary,Virtual,hci0) [hci0] 13.877604 @ RAW Open: 9496 (privileged) version 2.22 {0x0002} 13.890741 = Open Index: 00:00:00:00:00:00 [hci0] 13.900426 (...) > ACL Data RX: Handle 200 flags 0x00 dlen 1033 #32 [hci0] 14.273106 invalid packet size (12 != 1033) 08 00 01 00 02 01 04 00 01 10 ff ff ............ > ACL Data RX: Handle 200 flags 0x00 dlen 1547 #33 [hci0] 14.273561 invalid packet size (14 != 1547) 0a 00 01 00 04 01 06 00 40 00 00 00 00 00 ........@..... > ACL Data RX: Handle 200 flags 0x00 dlen 2061 #34 [hci0] 14.274390 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04 ........@....... > ACL Data RX: Handle 200 flags 0x00 dlen 2061 #35 [hci0] 14.274932 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00 ........@....... = bluetoothd: Bluetooth daemon 5.43 14.401828 > ACL Data RX: Handle 200 flags 0x00 dlen 1033 #36 [hci0] 14.275753 invalid packet size (12 ! • https://git.kernel.org/stable/c/49d5867819ab7c744852b45509e8469839c07e0e https://git.kernel.org/stable/c/95f1847a361c7b4bf7d74c06ecb6968455082c1a https://git.kernel.org/stable/c/ad528fde0702903208d0a79d88d5a42ae3fc235b https://git.kernel.org/stable/c/9fdc79b571434af7bc742da40a3405f038b637a7 https://git.kernel.org/stable/c/f3fe6817156a2ad4b06f01afab04638a34d7c9a6 https://git.kernel.org/stable/c/19a78143961a197de8502f4f29c453b913dc3c29 https://git.kernel.org/stable/c/5550bbf709c323194881737fd290c4bada9e6ead https://git.kernel.org/stable/c/bcd70260ef56e0aee8a4fc6cd214a4199 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2022-48946 – udf: Fix preallocation discarding at indirect extent boundary
https://notcve.org/view.php?id=CVE-2022-48946
In the Linux kernel, the following vulnerability has been resolved: udf: Fix preallocation discarding at indirect extent boundary When preallocation extent is the first one in the extent block, the code would corrupt extent tree header instead. Fix the problem and use udf_delete_aext() for deleting extent to avoid some code duplication. • https://git.kernel.org/stable/c/c8b6fa4511a7900db9fb0353b630d4d2ed1ba99c https://git.kernel.org/stable/c/7665857f88557c372da35534165721156756f77f https://git.kernel.org/stable/c/72f651c96c8aadf087fd782d551bf7db648a8c2e https://git.kernel.org/stable/c/4d835efd561dfb9bf5409f11f4ecd428d5d29226 https://git.kernel.org/stable/c/1a075f4a549481ce6e8518d8379f193ccec6b746 https://git.kernel.org/stable/c/63dbbd8f1499b0a161e701a04aa50148d60bd1f7 https://git.kernel.org/stable/c/ae56d9a017724f130cf1a263dd82a78d2a6e3852 https://git.kernel.org/stable/c/12a88f572d6d94b5c0b72e2d1782cc2e9 •
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/5d5e3b4cbe8ee16b7bf96fd73a421c92a9da3ca1 https://git.kernel.org/stable/c/88c2a10e6c176c2860cd0659f4c0e9d20b3f64d1 https://git.kernel.org/stable/c/28ead3eaabc16ecc907cfb71876da028080f6356 •