CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-38594 – net: stmmac: move the EST lock to struct stmmac_priv
https://notcve.org/view.php?id=CVE-2024-38594
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: move the EST lock to struct stmmac_priv Reinitialize the whole EST structure would also reset the mutex lock which is embedded in the EST structure, and then trigger the following warning. To address this, move the lock to struct stmmac_priv. We also need to reacquire the mutex lock when doing this initialization. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 505 at kernel/locking/mutex.c:587 __mutex_lock+0xd84/0x1068 Modules linked in: CPU: 3 PID: 505 Comm: tc Not tainted 6.9.0-rc6-00053-g0106679839f7-dirty #29 Hardware name: NXP i.MX8MPlus EVK board (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __mutex_lock+0xd84/0x1068 lr : __mutex_lock+0xd84/0x1068 sp : ffffffc0864e3570 x29: ffffffc0864e3570 x28: ffffffc0817bdc78 x27: 0000000000000003 x26: ffffff80c54f1808 x25: ffffff80c9164080 x24: ffffffc080d723ac x23: 0000000000000000 x22: 0000000000000002 x21: 0000000000000000 x20: 0000000000000000 x19: ffffffc083bc3000 x18: ffffffffffffffff x17: ffffffc08117b080 x16: 0000000000000002 x15: ffffff80d2d40000 x14: 00000000000002da x13: ffffff80d2d404b8 x12: ffffffc082b5a5c8 x11: ffffffc082bca680 x10: ffffffc082bb2640 x9 : ffffffc082bb2698 x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001 x5 : ffffff8178fe0d48 x4 : 0000000000000000 x3 : 0000000000000027 x2 : ffffff8178fe0d50 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: __mutex_lock+0xd84/0x1068 mutex_lock_nested+0x28/0x34 tc_setup_taprio+0x118/0x68c stmmac_setup_tc+0x50/0xf0 taprio_change+0x868/0xc9c En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: stmmac: mover el bloqueo EST a la estructura stmmac_priv Reinicializar toda la estructura EST también restablecería el bloqueo mutex que está incrustado en la estructura EST y luego activaría la siguiente advertencia. Para solucionar esto, mueva el candado a la estructura stmmac_priv. • https://git.kernel.org/stable/c/b2aae654a4794ef898ad33a179f341eb610f6b85 https://git.kernel.org/stable/c/b2091d47a14e8e6b3f03d792c1b25255d60b3219 https://git.kernel.org/stable/c/5ce4cc16d47186f0b76254e6f27beea25bafc1d9 https://git.kernel.org/stable/c/b538fefeb1026aad9dcdcbb410c42b56dff8aae9 https://git.kernel.org/stable/c/487f9030b1ef34bab123f2df2a4ccbe01ba84416 https://git.kernel.org/stable/c/6f476aff2d8da1a189621c4c16a76a6c534e4312 https://git.kernel.org/stable/c/36ac9e7f2e5786bd37c5cd91132e1f39c29b8197 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-38593 – net: micrel: Fix receiving the timestamp in the frame for lan8841
https://notcve.org/view.php?id=CVE-2024-38593
In the Linux kernel, the following vulnerability has been resolved: net: micrel: Fix receiving the timestamp in the frame for lan8841 The blamed commit started to use the ptp workqueue to get the second part of the timestamp. And when the port was set down, then this workqueue is stopped. But if the config option NETWORK_PHY_TIMESTAMPING is not enabled, then the ptp_clock is not initialized so then it would crash when it would try to access the delayed work. So then basically by setting up and then down the port, it would crash. The fix consists in checking if the ptp_clock is initialized and only then cancel the delayed work. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: micrel: Se corrigió la recepción de la marca de tiempo en el framework para lan8841. El commit culpable comenzó a usar la cola de trabajo ptp para obtener la segunda parte de la marca de tiempo. • https://git.kernel.org/stable/c/cc75549548482ed653c23f212544e58cb38ea980 https://git.kernel.org/stable/c/3ddf170e4a604f5d4d9459a36993f5e92b53e8b0 https://git.kernel.org/stable/c/3fd4282d5f25c3c97fef3ef0b89b82ef4e2bc975 https://git.kernel.org/stable/c/64a47cf634ae44e92be24ebc982410841093bd7b https://git.kernel.org/stable/c/aea27a92a41dae14843f92c79e9e42d8f570105c https://access.redhat.com/security/cve/CVE-2024-38593 https://bugzilla.redhat.com/show_bug.cgi?id=2293380 • CWE-457: Use of Uninitialized Variable •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-38592 – drm/mediatek: Init `ddp_comp` with devm_kcalloc()
https://notcve.org/view.php?id=CVE-2024-38592
In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Init `ddp_comp` with devm_kcalloc() In the case where `conn_routes` is true we allocate an extra slot in the `ddp_comp` array but mtk_drm_crtc_create() never seemed to initialize it in the test case I ran. For me, this caused a later crash when we looped through the array in mtk_drm_crtc_mode_valid(). This showed up for me when I booted with `slub_debug=FZPUA` which poisons the memory initially. Without `slub_debug` I couldn't reproduce, presumably because the later code handles the value being NULL and in most cases (not guaranteed in all cases) the memory the allocator returned started out as 0. It really doesn't hurt to initialize the array with devm_kcalloc() since the array is small and the overhead of initting a handful of elements to 0 is small. In general initting memory to zero is a safer practice and usually it's suggested to only use the non-initting alloc functions if you really need to. Let's switch the function to use an allocation function that zeros the memory. For me, this avoids the crash. • https://git.kernel.org/stable/c/01389b324c97ff8f04e9c33b9ee246084f9f6dd2 https://git.kernel.org/stable/c/cf69d0af7db917b82aceaa44b7b1b9376609da22 https://git.kernel.org/stable/c/9fe2cc3fa44f7ad7ba5f29c1a68b2b924c17b9b1 https://git.kernel.org/stable/c/01a2c5123e27b3c4685bf2fc4c2e879f6e0c7b33 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-38591 – RDMA/hns: Fix deadlock on SRQ async events.
https://notcve.org/view.php?id=CVE-2024-38591
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix deadlock on SRQ async events. xa_lock for SRQ table may be required in AEQ. Use xa_store_irq()/ xa_erase_irq() to avoid deadlock. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/hns: corrige el punto muerto en eventos asíncronos de SRQ. Es posible que se requiera xa_lock para la tabla SRQ en AEQ. Utilice xa_store_irq()/ xa_erase_irq() para evitar un punto muerto. • https://git.kernel.org/stable/c/81fce6291d9999cee692e4118134a8c850b60857 https://git.kernel.org/stable/c/4a3be1a0ffe04c085dd7f79be97c91b0c786df3d https://git.kernel.org/stable/c/756ddbe665ea7f9416951bd76731b174d136eea0 https://git.kernel.org/stable/c/22c915af31bd84ffaa46145e317f53333f94a868 https://git.kernel.org/stable/c/72dc542f0d8977e7d41d610db6bb65c47cad43e9 https://git.kernel.org/stable/c/d271e66abac5c7eb8de345b9b44d89f777437a4c https://git.kernel.org/stable/c/b46494b6f9c19f141114a57729e198698f40af37 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-38590 – RDMA/hns: Modify the print level of CQE error
https://notcve.org/view.php?id=CVE-2024-38590
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Modify the print level of CQE error Too much print may lead to a panic in kernel. Change ibdev_err() to ibdev_err_ratelimited(), and change the printing level of cqe dump to debug level. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/hns: Modifique el nivel de impresión del error CQE. Demasiada impresión puede provocar pánico en el kernel. Cambie ibdev_err() a ibdev_err_ratelimited() y cambie el nivel de impresión del volcado cqe al nivel de depuración. • https://git.kernel.org/stable/c/7c044adca272768d821921f11d3da4587dcec68a https://git.kernel.org/stable/c/45b31be4dd22827903df15c548b97b416790139b https://git.kernel.org/stable/c/cc699b7eb2bc963c12ffcd37f80f45330d2924bd https://git.kernel.org/stable/c/17f3741c65c4a042ae8ba094068b07a4b77e213c https://git.kernel.org/stable/c/6f541a89ced8305da459e3ab0006e7528cf7da7b https://git.kernel.org/stable/c/817a10a6df9354e67561922d2b7fce48dfbebc55 https://git.kernel.org/stable/c/06cf121346bbd3d83a5eea05bb87666c6b279990 https://git.kernel.org/stable/c/349e859952285ab9689779fb46de163f1 •