CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-42294 – block: fix deadlock between sd_remove & sd_release
https://notcve.org/view.php?id=CVE-2024-42294
In the Linux kernel, the following vulnerability has been resolved: block: fix deadlock between sd_remove & sd_release Our test report the following hung task: [ 2538.459400] INFO: task "kworker/0:0":7 blocked for more than 188 seconds. [ 2538.459427] Call trace: [ 2538.459430] __switch_to+0x174/0x338 [ 2538.459436] __schedule+0x628/0x9c4 [ 2538.459442] schedule+0x7c/0xe8 [ 2538.459447] schedule_preempt_disabled+0x24/0x40 [ 2538.459453] __mutex_lock+0x3ec/0xf04 [ 2538.459456] __mutex_lock_slowpath+0x14/0x24 [ 2538.459459] mutex_lock+0x30/0xd8 [ 2538.459462] del_gendisk+0xdc/0x350 [ 2538.459466] sd_remove+0x30/0x60 [ 2538.459470] device_release_driver_internal+0x1c4/0x2c4 [ 2538.459474] device_release_driver+0x18/0x28 [ 2538.459478] bus_remove_device+0x15c/0x174 [ 2538.459483] device_del+0x1d0/0x358 [ 2538.459488] __scsi_remove_device+0xa8/0x198 [ 2538.459493] scsi_forget_host+0x50/0x70 [ 2538.459497] scsi_remove_host+0x80/0x180 [ 2538.459502] usb_stor_disconnect+0x68/0xf4 [ 2538.459506] usb_unbind_interface+0xd4/0x280 [ 2538.459510] device_release_driver_internal+0x1c4/0x2c4 [ 2538.459514] device_release_driver+0x18/0x28 [ 2538.459518] bus_remove_device+0x15c/0x174 [ 2538.459523] device_del+0x1d0/0x358 [ 2538.459528] usb_disable_device+0x84/0x194 [ 2538.459532] usb_disconnect+0xec/0x300 [ 2538.459537] hub_event+0xb80/0x1870 [ 2538.459541] process_scheduled_works+0x248/0x4dc [ 2538.459545] worker_thread+0x244/0x334 [ 2538.459549] kthread+0x114/0x1bc [ 2538.461001] INFO: task "fsck.":15415 blocked for more than 188 seconds. [ 2538.461014] Call trace: [ 2538.461016] __switch_to+0x174/0x338 [ 2538.461021] __schedule+0x628/0x9c4 [ 2538.461025] schedule+0x7c/0xe8 [ 2538.461030] blk_queue_enter+0xc4/0x160 [ 2538.461034] blk_mq_alloc_request+0x120/0x1d4 [ 2538.461037] scsi_execute_cmd+0x7c/0x23c [ 2538.461040] ioctl_internal_command+0x5c/0x164 [ 2538.461046] scsi_set_medium_removal+0x5c/0xb0 [ 2538.461051] sd_release+0x50/0x94 [ 2538.461054] blkdev_put+0x190/0x28c [ 2538.461058] blkdev_release+0x28/0x40 [ 2538.461063] __fput+0xf8/0x2a8 [ 2538.461066] __fput_sync+0x28/0x5c [ 2538.461070] __arm64_sys_close+0x84/0xe8 [ 2538.461073] invoke_syscall+0x58/0x114 [ 2538.461078] el0_svc_common+0xac/0xe0 [ 2538.461082] do_el0_svc+0x1c/0x28 [ 2538.461087] el0_svc+0x38/0x68 [ 2538.461090] el0t_64_sync_handler+0x68/0xbc [ 2538.461093] el0t_64_sync+0x1a8/0x1ac T1: T2: sd_remove del_gendisk __blk_mark_disk_dead blk_freeze_queue_start ++q->mq_freeze_depth bdev_release mutex_lock(&disk->open_mutex) sd_release scsi_execute_cmd blk_queue_enter wait_event(!q->mq_freeze_depth) mutex_lock(&disk->open_mutex) SCSI does not set GD_OWNS_QUEUE, so QUEUE_FLAG_DYING is not set in this scenario. This is a classic ABBA deadlock. • https://git.kernel.org/stable/c/eec1be4c30df73238b936fa9f3653773a6f8b15c https://git.kernel.org/stable/c/5a5625a83eac91fdff1d5f0202ecfc45a31983c9 https://git.kernel.org/stable/c/f5418f48a93b69ed9e6a2281eee06b412f14a544 https://git.kernel.org/stable/c/7e04da2dc7013af50ed3a2beb698d5168d1e594b •
CVSS: 6.1EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42292 – kobject_uevent: Fix OOB access within zap_modalias_env()
https://notcve.org/view.php?id=CVE-2024-42292
In the Linux kernel, the following vulnerability has been resolved: kobject_uevent: Fix OOB access within zap_modalias_env() zap_modalias_env() wrongly calculates size of memory block to move, so will cause OOB memory access issue if variable MODALIAS is not the last one within its @env parameter, fixed by correcting size to memmove. • https://git.kernel.org/stable/c/9b3fa47d4a76b1d606a396455f9bbeee083ef008 https://git.kernel.org/stable/c/81a15d28f32af01493ae8c5457e0d55314a4167d https://git.kernel.org/stable/c/b59a5e86a3934f1b6a5bd1368902dbc79bdecc90 https://git.kernel.org/stable/c/648d5490460d38436640da0812bf7f6351c150d2 https://git.kernel.org/stable/c/c5ee8adc8d98a49703320d13878ba2b923b142f5 https://git.kernel.org/stable/c/68d63ace80b76395e7935687ecdb86421adc2168 https://git.kernel.org/stable/c/57fe01d3d04276875c7e3a6dc763517fc05b8762 https://git.kernel.org/stable/c/d4663536754defff75ff1eca0aaebc41d • CWE-125: Out-of-bounds Read •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-42291 – ice: Add a per-VF limit on number of FDIR filters
https://notcve.org/view.php?id=CVE-2024-42291
In the Linux kernel, the following vulnerability has been resolved: ice: Add a per-VF limit on number of FDIR filters While the iavf driver adds a s/w limit (128) on the number of FDIR filters that the VF can request, a malicious VF driver can request more than that and exhaust the resources for other VFs. Add a similar limit in ice. • https://git.kernel.org/stable/c/1f7ea1cd6a3748427512ccc9582e18cd9efea966 https://git.kernel.org/stable/c/8e02cd98a6e24389d476e28436d41e620ed8e559 https://git.kernel.org/stable/c/d62389073a5b937413e2d1bc1da06ccff5103c0c https://git.kernel.org/stable/c/292081c4e7f575a79017d5cbe1a0ec042783976f https://git.kernel.org/stable/c/6ebbe97a488179f5dc85f2f1e0c89b486e99ee97 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-42290 – irqchip/imx-irqsteer: Handle runtime power management correctly
https://notcve.org/view.php?id=CVE-2024-42290
In the Linux kernel, the following vulnerability has been resolved: irqchip/imx-irqsteer: Handle runtime power management correctly The power domain is automatically activated from clk_prepare(). However, on certain platforms like i.MX8QM and i.MX8QXP, the power-on handling invokes sleeping functions, which triggers the 'scheduling while atomic' bug in the context switch path during device probing: BUG: scheduling while atomic: kworker/u13:1/48/0x00000002 Call trace: __schedule_bug+0x54/0x6c __schedule+0x7f0/0xa94 schedule+0x5c/0xc4 schedule_preempt_disabled+0x24/0x40 __mutex_lock.constprop.0+0x2c0/0x540 __mutex_lock_slowpath+0x14/0x20 mutex_lock+0x48/0x54 clk_prepare_lock+0x44/0xa0 clk_prepare+0x20/0x44 imx_irqsteer_resume+0x28/0xe0 pm_generic_runtime_resume+0x2c/0x44 __genpd_runtime_resume+0x30/0x80 genpd_runtime_resume+0xc8/0x2c0 __rpm_callback+0x48/0x1d8 rpm_callback+0x6c/0x78 rpm_resume+0x490/0x6b4 __pm_runtime_resume+0x50/0x94 irq_chip_pm_get+0x2c/0xa0 __irq_do_set_handler+0x178/0x24c irq_set_chained_handler_and_data+0x60/0xa4 mxc_gpio_probe+0x160/0x4b0 Cure this by implementing the irq_bus_lock/sync_unlock() interrupt chip callbacks and handle power management in them as they are invoked from non-atomic context. [ tglx: Rewrote change log, added Fixes tag ] • https://git.kernel.org/stable/c/0136afa08967f6e160b9b4e85a7a70e4180a8333 https://git.kernel.org/stable/c/a590e8dea3df2639921f874d763be961dd74e8f9 https://git.kernel.org/stable/c/3a2884a44e5cda192df1b28e9925661f79f599a1 https://git.kernel.org/stable/c/fa1803401e1c360efe6342fb41d161cc51748a11 https://git.kernel.org/stable/c/58c56735facb225a5c46fa4b8bbbe7f31d1cb894 https://git.kernel.org/stable/c/21bd3f9e7f924cd2fc892a484e7a50c7e1847565 https://git.kernel.org/stable/c/f8ae38f1dfe652779c7c613facbc257cec00ac44 https://git.kernel.org/stable/c/33b1c47d1fc0b5f06a393bb915db85baa •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42289 – scsi: qla2xxx: During vport delete send async logout explicitly
https://notcve.org/view.php?id=CVE-2024-42289
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: During vport delete send async logout explicitly During vport delete, it is observed that during unload we hit a crash because of stale entries in outstanding command array. For all these stale I/O entries, eh_abort was issued and aborted (fast_fail_io = 2009h) but I/Os could not complete while vport delete is in process of deleting. BUG: kernel NULL pointer dereference, address: 000000000000001c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI Workqueue: qla2xxx_wq qla_do_work [qla2xxx] RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0 RSP: 0018:ffffa1e1e150fc68 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000001 RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8ce208a7a0d0 RBP: ffff8ce208a7a0d0 R08: 0000000000000000 R09: ffff8ce378aac9c8 R10: ffff8ce378aac8a0 R11: ffffa1e1e150f9d8 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8ce378aac9c8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8d217f000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001c CR3: 0000002089acc000 CR4: 0000000000350ee0 Call Trace: <TASK> qla2xxx_qpair_sp_free_dma+0x417/0x4e0 ? qla2xxx_qpair_sp_compl+0x10d/0x1a0 ? qla2x00_status_entry+0x768/0x2830 ? newidle_balance+0x2f0/0x430 ? • https://git.kernel.org/stable/c/086489256696eb774654a5410e86381c346356fe https://git.kernel.org/stable/c/171ac4b495f9473bc134356a00095b47e6409e52 https://git.kernel.org/stable/c/e5ed6a26ffdec0c91cf0b6138afbd675c00ad5fc https://git.kernel.org/stable/c/b12c54e51ba83c1fbc619d35083d7872e42ecdef https://git.kernel.org/stable/c/d28a2075bb530489715a3b011e1dd8765ba20313 https://git.kernel.org/stable/c/87c25fcb95aafabb6a4914239f4ab41b07a4f9b7 https://git.kernel.org/stable/c/b35d6d5a2f38605cddea7d5c64cded894fbe8ede https://git.kernel.org/stable/c/76f480d7c717368f29a3870f7d64471ce •