CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-49866 – tracing/timerlat: Fix a race during cpuhp processing
https://notcve.org/view.php?id=CVE-2024-49866
In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? • https://git.kernel.org/stable/c/c8895e271f7994a3ecb13b8a280e39aa53879545 https://git.kernel.org/stable/c/322920b53dc11f9c2b33397eb3ae5bc6a175b60d https://git.kernel.org/stable/c/ce25f33ba89d6eefef64157655d318444580fa14 https://git.kernel.org/stable/c/a6e9849063a6c8f4cb2f652a437e44e3ed24356c https://git.kernel.org/stable/c/a0d9c0cd5856191e095cf43a2e141b73945b7716 https://git.kernel.org/stable/c/f72b451dc75578f644a3019c1489e9ae2c14e6c4 https://git.kernel.org/stable/c/829e0c9f0855f26b3ae830d17b24aec103f7e915 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-49864 – rxrpc: Fix a race between socket set up and I/O thread creation
https://notcve.org/view.php?id=CVE-2024-49864
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix a race between socket set up and I/O thread creation In rxrpc_open_socket(), it sets up the socket and then sets up the I/O thread that will handle it. This is a problem, however, as there's a gap between the two phases in which a packet may come into rxrpc_encap_rcv() from the UDP packet but we oops when trying to wake the not-yet created I/O thread. As a quick fix, just make rxrpc_encap_rcv() discard the packet if there's no I/O thread yet. A better, but more intrusive fix would perhaps be to rearrange things such that the socket creation is done by the I/O thread. • https://git.kernel.org/stable/c/a275da62e8c111b897b9cb73eb91df2f4e475ca5 https://git.kernel.org/stable/c/cdf4bbbdb956d7426f687f38757ebca2a2759a0f https://git.kernel.org/stable/c/56e415202b8a17de6496f4023e545fcb66f118ec https://git.kernel.org/stable/c/c64f5fc95e9612fdf75587c8e21e494e614c18e2 https://git.kernel.org/stable/c/bc212465326e8587325f520a052346f0b57360e6 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-49863 – vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()
https://notcve.org/view.php?id=CVE-2024-49863
In the Linux kernel, the following vulnerability has been resolved: vhost/scsi: null-ptr-dereference in vhost_scsi_get_req() Since commit 3f8ca2e115e5 ("vhost/scsi: Extract common handling code from control queue handler") a null pointer dereference bug can be triggered when guest sends an SCSI AN request. In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with `&v_req.tmf.lun[1]` within a switch-case block and is then passed to vhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, for a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is set to NULL in this branch. Later, in vhost_scsi_get_req(), `vc->target` is dereferenced without being checked, leading to a null pointer dereference bug. This bug can be triggered from guest. When this bug occurs, the vhost_worker process is killed while holding `vq->mutex` and the corresponding tpg will remain occupied indefinitely. Below is the KASAN report: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1 Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vhost_scsi_get_req+0x165/0x3a0 Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b6 04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00 RSP: 0018:ffff888017affb50 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8 RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000 FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0 Call Trace: <TASK> ? show_regs+0x86/0xa0 ? • https://git.kernel.org/stable/c/3f8ca2e115e55af4c15d97dda635e948d2e380be https://git.kernel.org/stable/c/6592347f06e2b19a624270a85ad4b3ae48c3b241 https://git.kernel.org/stable/c/46128370a72c431df733af5ebb065c4d48c9ad39 https://git.kernel.org/stable/c/ace9c778a214da9c98d7b69d904d1b0816f4f681 https://git.kernel.org/stable/c/25613e6d9841a1f9fb985be90df921fa99f800de https://git.kernel.org/stable/c/00fb5b23e1c9cdbe496f5cd6b40367cb895f6c93 https://git.kernel.org/stable/c/61517f33e76d2c5247c1e61e668693afe5b67e6f https://git.kernel.org/stable/c/221af82f606d928ccef19a16d35633c63 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-49862 – powercap: intel_rapl: Fix off by one in get_rpi()
https://notcve.org/view.php?id=CVE-2024-49862
In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix off by one in get_rpi() The rp->priv->rpi array is either rpi_msr or rpi_tpmi which have NR_RAPL_PRIMITIVES number of elements. Thus the > needs to be >= to prevent an off by one access. • https://git.kernel.org/stable/c/98ff639a7289067247b3ef9dd5d1e922361e7365 https://git.kernel.org/stable/c/288cbc505e2046638c615c36357cb78bc9fee1e0 https://git.kernel.org/stable/c/851e7f7f14a15f4e47b7d0f70d5c4a2b95b824d6 https://git.kernel.org/stable/c/6a34f3b0d7f11fb6ed72da315fd2360abd9c0737 https://git.kernel.org/stable/c/95f6580352a7225e619551febb83595bcb77ab17 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-49861 – bpf: Fix helper writes to read-only maps
https://notcve.org/view.php?id=CVE-2024-49861
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta->raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via *<ptr> = val. The .arg*_size has been initialized reflecting the actual sizeof(*<ptr>). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in ! • https://git.kernel.org/stable/c/57c3bb725a3dd97d960d7e1cd0845d88de53217f https://git.kernel.org/stable/c/a2c8dc7e21803257e762b0bf067fd13e9c995da0 https://git.kernel.org/stable/c/2ed98ee02d1e08afee88f54baec39ea78dc8a23c https://git.kernel.org/stable/c/1e75d25133158b525e0456876e9bcfd6b2993fd5 https://git.kernel.org/stable/c/32556ce93bc45c730829083cb60f95a2728ea48b •