CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-49865 – drm/xe/vm: move xa_alloc to prevent UAF
https://notcve.org/view.php?id=CVE-2024-49865
In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: move xa_alloc to prevent UAF Evil user can guess the next id of the vm before the ioctl completes and then call vm destroy ioctl to trigger UAF since create ioctl is still referencing the same vm. Move the xa_alloc all the way to the end to prevent this. v2: - Rebase (cherry picked from commit dcfd3971327f3ee92765154baebbaece833d3ca9) • https://git.kernel.org/stable/c/dd08ebf6c3525a7ea2186e636df064ea47281987 https://git.kernel.org/stable/c/09cf8901fc0225898311b375cfcc67bae37ed5da https://git.kernel.org/stable/c/74231870cf4976f69e83aa24f48edb16619f652f •
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 •