CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-39292 – um: Add winch to winch_handlers before registering winch IRQ
https://notcve.org/view.php?id=CVE-2024-39292
In the Linux kernel, the following vulnerability has been resolved: um: Add winch to winch_handlers before registering winch IRQ Registering a winch IRQ is racy, an interrupt may occur before the winch is added to the winch_handlers list. If that happens, register_winch_irq() adds to that list a winch that is scheduled to be (or has already been) freed, causing a panic later in winch_cleanup(). Avoid the race by adding the winch to the winch_handlers list before registering the IRQ, and rolling back if um_request_irq() fails. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: um: Agregar cabrestante a winch_handlers antes de registrar la IRQ del cabrestante Registrar una IRQ del cabrestante es picante, puede ocurrir una interrupción antes de que el cabrestante se agregue a la lista de winch_handlers. Si eso sucede, Register_winch_irq() agrega a esa lista un cabrestante que está programado para ser liberado (o que ya ha sido) liberado, causando pánico más adelante en winch_cleanup(). Evite la ejecución agregando el cabrestante a la lista winch_handlers antes de registrar la IRQ y retrocediendo si um_request_irq() falla. • https://git.kernel.org/stable/c/42a359e31a0e438b5b978a8f0fecdbd3c86bb033 https://git.kernel.org/stable/c/66ea9a7c6824821476914bed21a476cd20094f33 https://git.kernel.org/stable/c/dc1ff95602ee908fcd7d8acee7a0dadb61b1a0c0 https://git.kernel.org/stable/c/351d1a64544944b44732f6a64ed65573b00b9e14 https://git.kernel.org/stable/c/31960d991e43c8d6dc07245f19fc13398e90ead2 https://git.kernel.org/stable/c/0c02d425a2fbe52643a5859a779db0329e7dddd4 https://git.kernel.org/stable/c/434a06c38ee1217a8baa0dd7c37cc85d50138fb0 https://git.kernel.org/stable/c/73b8e21f76c7dda4905655d2e2c17dc5a • CWE-415: Double Free •
CVSS: 7.8EPSS: 0%CPEs: 4EXPL: 0CVE-2024-38667 – riscv: prevent pt_regs corruption for secondary idle threads
https://notcve.org/view.php?id=CVE-2024-38667
In the Linux kernel, the following vulnerability has been resolved: riscv: prevent pt_regs corruption for secondary idle threads Top of the kernel thread stack should be reserved for pt_regs. However this is not the case for the idle threads of the secondary boot harts. Their stacks overlap with their pt_regs, so both may get corrupted. Similar issue has been fixed for the primary hart, see c7cdd96eca28 ("riscv: prevent stack corruption by reserving task_pt_regs(p) early"). However that fix was not propagated to the secondary harts. The problem has been noticed in some CPU hotplug tests with V enabled. The function smp_callin stored several registers on stack, corrupting top of pt_regs structure including status field. As a result, kernel attempted to save or restore inexistent V context. • https://git.kernel.org/stable/c/2875fe0561569f82d0e63658ccf0d11ce7da8922 https://git.kernel.org/stable/c/ea22d4195cca13d5fdbc4d6555a2dfb8a7867a9e https://git.kernel.org/stable/c/3090c06d50eaa91317f84bf3eac4c265e6cb8d44 https://git.kernel.org/stable/c/0c1f28c32a194303da630fca89481334b9547b80 https://git.kernel.org/stable/c/a638b0461b58aa3205cd9d5f14d6f703d795b4af • CWE-787: Out-of-bounds Write •
CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0CVE-2024-38664 – drm: zynqmp_dpsub: Always register bridge
https://notcve.org/view.php?id=CVE-2024-38664
In the Linux kernel, the following vulnerability has been resolved: drm: zynqmp_dpsub: Always register bridge We must always register the DRM bridge, since zynqmp_dp_hpd_work_func calls drm_bridge_hpd_notify, which in turn expects hpd_mutex to be initialized. We do this before zynqmp_dpsub_drm_init since that calls drm_bridge_attach. This fixes the following lockdep warning: [ 19.217084] ------------[ cut here ]------------ [ 19.227530] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 19.227768] WARNING: CPU: 0 PID: 140 at kernel/locking/mutex.c:582 __mutex_lock+0x4bc/0x550 [ 19.241696] Modules linked in: [ 19.244937] CPU: 0 PID: 140 Comm: kworker/0:4 Not tainted 6.6.20+ #96 [ 19.252046] Hardware name: xlnx,zynqmp (DT) [ 19.256421] Workqueue: events zynqmp_dp_hpd_work_func [ 19.261795] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 19.269104] pc : __mutex_lock+0x4bc/0x550 [ 19.273364] lr : __mutex_lock+0x4bc/0x550 [ 19.277592] sp : ffffffc085c5bbe0 [ 19.281066] x29: ffffffc085c5bbe0 x28: 0000000000000000 x27: ffffff88009417f8 [ 19.288624] x26: ffffff8800941788 x25: ffffff8800020008 x24: ffffffc082aa3000 [ 19.296227] x23: ffffffc080d90e3c x22: 0000000000000002 x21: 0000000000000000 [ 19.303744] x20: 0000000000000000 x19: ffffff88002f5210 x18: 0000000000000000 [ 19.311295] x17: 6c707369642e3030 x16: 3030613464662072 x15: 0720072007200720 [ 19.318922] x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 0000000000000001 [ 19.326442] x11: 0001ffc085c5b940 x10: 0001ff88003f388b x9 : 0001ff88003f3888 [ 19.334003] x8 : 0001ff88003f3888 x7 : 0000000000000000 x6 : 0000000000000000 [ 19.341537] x5 : 0000000000000000 x4 : 0000000000001668 x3 : 0000000000000000 [ 19.349054] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff88003f3880 [ 19.356581] Call trace: [ 19.359160] __mutex_lock+0x4bc/0x550 [ 19.363032] mutex_lock_nested+0x24/0x30 [ 19.367187] drm_bridge_hpd_notify+0x2c/0x6c [ 19.371698] zynqmp_dp_hpd_work_func+0x44/0x54 [ 19.376364] process_one_work+0x3ac/0x988 [ 19.380660] worker_thread+0x398/0x694 [ 19.384736] kthread+0x1bc/0x1c0 [ 19.388241] ret_from_fork+0x10/0x20 [ 19.392031] irq event stamp: 183 [ 19.395450] hardirqs last enabled at (183): [<ffffffc0800b9278>] finish_task_switch.isra.0+0xa8/0x2d4 [ 19.405140] hardirqs last disabled at (182): [<ffffffc081ad3754>] __schedule+0x714/0xd04 [ 19.413612] softirqs last enabled at (114): [<ffffffc080133de8>] srcu_invoke_callbacks+0x158/0x23c [ 19.423128] softirqs last disabled at (110): [<ffffffc080133de8>] srcu_invoke_callbacks+0x158/0x23c [ 19.432614] ---[ end trace 0000000000000000 ]--- (cherry picked from commit 61ba791c4a7a09a370c45b70a81b8c7d4cf6b2ae) En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: drm: zynqmp_dpsub: Registrar siempre puente Siempre debemos registrar el puente DRM, ya que zynqmp_dp_hpd_work_func llama a drm_bridge_hpd_notify, que a su vez espera que hpd_mutex se inicialice. Hacemos esto antes de zynqmp_dpsub_drm_init ya que llama a drm_bridge_attach. • https://git.kernel.org/stable/c/eb2d64bfcc174919a921295a5327b99a3b8f4166 https://git.kernel.org/stable/c/6ead3eccf67bc8318b1ce95ed879b2cc05b4fce9 https://git.kernel.org/stable/c/603661357056b5e5ba6d86f505fbc936eff396ba https://git.kernel.org/stable/c/be3f3042391d061cfca2bd22630e0d101acea5fc • CWE-667: Improper Locking •
CVSS: 4.4EPSS: 0%CPEs: 3EXPL: 0CVE-2024-38663 – blk-cgroup: fix list corruption from resetting io stat
https://notcve.org/view.php?id=CVE-2024-38663
In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix list corruption from resetting io stat Since commit 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()"), each iostat instance is added to blkcg percpu list, so blkcg_reset_stats() can't reset the stat instance by memset(), otherwise the llist may be corrupted. Fix the issue by only resetting the counter part. • https://git.kernel.org/stable/c/3b8cc6298724021da845f2f9fd7dd4b6829a6817 https://git.kernel.org/stable/c/d4a60298ac34f027a09f8f893fdbd9e06279bb24 https://git.kernel.org/stable/c/89bb36c72e1951843f9e04dc84412e31fcc849a9 https://git.kernel.org/stable/c/6da6680632792709cecf2b006f2fe3ca7857e791 https://access.redhat.com/security/cve/CVE-2024-38663 https://bugzilla.redhat.com/show_bug.cgi?id=2294225 • CWE-665: Improper Initialization •
CVSS: 8.4EPSS: 0%CPEs: 3EXPL: 0CVE-2024-38384 – blk-cgroup: fix list corruption from reorder of WRITE ->lqueued
https://notcve.org/view.php?id=CVE-2024-38384
In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix list corruption from reorder of WRITE ->lqueued __blkcg_rstat_flush() can be run anytime, especially when blk_cgroup_bio_start is being executed. If WRITE of `->lqueued` is re-ordered with READ of 'bisc->lnode.next' in the loop of __blkcg_rstat_flush(), `next_bisc` can be assigned with one stat instance being added in blk_cgroup_bio_start(), then the local list in __blkcg_rstat_flush() could be corrupted. Fix the issue by adding one barrier. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: blk-cgroup: corrupción de la lista de arreglos debido al reordenamiento de WRITE ->lqueued __blkcg_rstat_flush() se puede ejecutar en cualquier momento, especialmente cuando se está ejecutando blk_cgroup_bio_start. Si la ESCRITURA de `->lqueued` se reordena con la READ de 'bisc->lnode.next' en el bucle de __blkcg_rstat_flush(), se puede asignar `next_bisc` agregando una instancia de estadística en blk_cgroup_bio_start(), entonces el La lista local en __blkcg_rstat_flush() podría estar dañada. Solucione el problema agregando una barrera. • https://git.kernel.org/stable/c/3b8cc6298724021da845f2f9fd7dd4b6829a6817 https://git.kernel.org/stable/c/714e59b5456e4d6e4295a9968c564abe193f461c https://git.kernel.org/stable/c/785298ab6b802afa75089239266b6bbea590809c https://git.kernel.org/stable/c/d0aac2363549e12cc79b8e285f13d5a9f42fd08e https://access.redhat.com/security/cve/CVE-2024-38384 https://bugzilla.redhat.com/show_bug.cgi?id=2294220 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') CWE-400: Uncontrolled Resource Consumption •