CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-44996 – vsock: fix recursive ->recvmsg calls
https://notcve.org/view.php?id=CVE-2024-44996
In the Linux kernel, the following vulnerability has been resolved: vsock: fix recursive ->recvmsg calls After a vsock socket has been added to a BPF sockmap, its prot->recvmsg has been replaced with vsock_bpf_recvmsg(). Thus the following recursiion could happen: vsock_bpf_recvmsg() -> __vsock_recvmsg() -> vsock_connectible_recvmsg() -> prot->recvmsg() -> vsock_bpf_recvmsg() again We need to fix it by calling the original ->recvmsg() without any BPF sockmap logic in __vsock_recvmsg(). • https://git.kernel.org/stable/c/634f1a7110b439c65fd8a809171c1d2d28bcea6f https://git.kernel.org/stable/c/921f1acf0c3cf6b1260ab57a8a6e8b3d5f3023d5 https://git.kernel.org/stable/c/b4ee8cf1acc5018ed1369150d7bb3e0d0f79e135 https://git.kernel.org/stable/c/69139d2919dd4aa9a553c8245e7c63e82613e3fc •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-44995 – net: hns3: fix a deadlock problem when config TC during resetting
https://notcve.org/view.php?id=CVE-2024-44995
In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix a deadlock problem when config TC during resetting When config TC during the reset process, may cause a deadlock, the flow is as below: pf reset start │ ▼ ...... setup tc │ │ ▼ ▼ DOWN: napi_disable() napi_disable()(skip) │ │ │ ▼ ▼ ...... ...... │ │ ▼ │ napi_enable() │ ▼ UINIT: netif_napi_del() │ ▼ ...... │ ▼ INIT: netif_napi_add() │ ▼ ...... global reset start │ │ ▼ ▼ UP: napi_enable()(skip) ...... │ │ ▼ ▼ ...... napi_disable() In reset process, the driver will DOWN the port and then UINIT, in this case, the setup tc process will UP the port before UINIT, so cause the problem. Adds a DOWN process in UINIT to fix it. • https://git.kernel.org/stable/c/bb6b94a896d4dd4dcdeccca87c3fd22521c652c0 https://git.kernel.org/stable/c/67492d4d105c0a6321b00c393eec96b9a7a97a16 https://git.kernel.org/stable/c/fc250eca15bde34c4c8f806b9d88f55bd56a992c https://git.kernel.org/stable/c/195918217448a6bb7f929d6a2ffffce9f1ece1cc https://git.kernel.org/stable/c/6ae2b7d63cd056f363045eb65409143e16f23ae8 https://git.kernel.org/stable/c/fa1d4de7265c370e673583ac8d1bd17d21826cd9 https://git.kernel.org/stable/c/de37408d5c26fc4a296a28a0c96dcb814219bfa1 https://git.kernel.org/stable/c/be5e816d00a506719e9dbb1a9c861c5ce •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-44994 – iommu: Restore lost return in iommu_report_device_fault()
https://notcve.org/view.php?id=CVE-2024-44994
In the Linux kernel, the following vulnerability has been resolved: iommu: Restore lost return in iommu_report_device_fault() When iommu_report_device_fault gets called with a partial fault it is supposed to collect the fault into the group and then return. Instead the return was accidently deleted which results in trying to process the fault and an eventual crash. Deleting the return was a typo, put it back. • https://git.kernel.org/stable/c/3dfa64aecbafc288216b2790438d395add192c30 https://git.kernel.org/stable/c/cc6bc2ab1663ec9353636416af22452b078510e9 https://git.kernel.org/stable/c/fca5b78511e98bdff2cdd55c172b23200a7b3404 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-44993 – drm/v3d: Fix out-of-bounds read in `v3d_csd_job_run()`
https://notcve.org/view.php?id=CVE-2024-44993
In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix out-of-bounds read in `v3d_csd_job_run()` When enabling UBSAN on Raspberry Pi 5, we get the following warning: [ 387.894977] UBSAN: array-index-out-of-bounds in drivers/gpu/drm/v3d/v3d_sched.c:320:3 [ 387.903868] index 7 is out of range for type '__u32 [7]' [ 387.909692] CPU: 0 PID: 1207 Comm: kworker/u16:2 Tainted: G WC 6.10.3-v8-16k-numa #151 [ 387.919166] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT) [ 387.925961] Workqueue: v3d_csd drm_sched_run_job_work [gpu_sched] [ 387.932525] Call trace: [ 387.935296] dump_backtrace+0x170/0x1b8 [ 387.939403] show_stack+0x20/0x38 [ 387.942907] dump_stack_lvl+0x90/0xd0 [ 387.946785] dump_stack+0x18/0x28 [ 387.950301] __ubsan_handle_out_of_bounds+0x98/0xd0 [ 387.955383] v3d_csd_job_run+0x3a8/0x438 [v3d] [ 387.960707] drm_sched_run_job_work+0x520/0x6d0 [gpu_sched] [ 387.966862] process_one_work+0x62c/0xb48 [ 387.971296] worker_thread+0x468/0x5b0 [ 387.975317] kthread+0x1c4/0x1e0 [ 387.978818] ret_from_fork+0x10/0x20 [ 387.983014] ---[ end trace ]--- This happens because the UAPI provides only seven configuration registers and we are reading the eighth position of this u32 array. Therefore, fix the out-of-bounds read in `v3d_csd_job_run()` by accessing only seven positions on the '__u32 [7]' array. The eighth register exists indeed on V3D 7.1, but it isn't currently used. That being so, let's guarantee that it remains unused and add a note that it could be set in a future patch. • https://git.kernel.org/stable/c/0ad5bc1ce4634ce9b5eaf017b01399ec5e49a03d https://git.kernel.org/stable/c/d656b82c4b30cf12715e6cd129d3df808fde24a7 https://git.kernel.org/stable/c/497d370a644d95a9f04271aa92cb96d32e84c770 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-44992 – smb/client: avoid possible NULL dereference in cifs_free_subrequest()
https://notcve.org/view.php?id=CVE-2024-44992
In the Linux kernel, the following vulnerability has been resolved: smb/client: avoid possible NULL dereference in cifs_free_subrequest() Clang static checker (scan-build) warning: cifsglob.h:line 890, column 3 Access to field 'ops' results in a dereference of a null pointer. Commit 519be989717c ("cifs: Add a tracepoint to track credits involved in R/W requests") adds a check for 'rdata->server', and let clang throw this warning about NULL dereference. When 'rdata->credits.value != 0 && rdata->server == NULL' happens, add_credits_and_wake_if() will call rdata->server->ops->add_credits(). This will cause NULL dereference problem. Add a check for 'rdata->server' to avoid NULL dereference. • https://git.kernel.org/stable/c/69c3c023af25edb5433a2db824d3e7cc328f0183 https://git.kernel.org/stable/c/fead60a6d5f84b472b928502a42c419253afe6c1 https://git.kernel.org/stable/c/74c2ab6d653b4c2354df65a7f7f2df1925a40a51 •