CVSS: 7.8EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26934 – USB: core: Fix deadlock in usb_deauthorize_interface()
https://notcve.org/view.php?id=CVE-2024-26934
In the Linux kernel, the following vulnerability has been resolved: USB: core: Fix deadlock in usb_deauthorize_interface() Among the attribute file callback routines in drivers/usb/core/sysfs.c, the interface_authorized_store() function is the only one which acquires a device lock on an ancestor device: It calls usb_deauthorize_interface(), which locks the interface's parent USB device. The will lead to deadlock if another process already owns that lock and tries to remove the interface, whether through a configuration change or because the device has been disconnected. As part of the removal procedure, device_del() waits for all ongoing sysfs attribute callbacks to complete. But usb_deauthorize_interface() can't complete until the device lock has been released, and the lock won't be released until the removal has finished. The mechanism provided by sysfs to prevent this kind of deadlock is to use the sysfs_break_active_protection() function, which tells sysfs not to wait for the attribute callback. Reported-and-tested by: Yue Sun <samsun1006219@gmail.com> Reported by: xingwei lee <xrivendell7@gmail.com> En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: core: corrige el punto muerto en usb_deauthorize_interface() Entre las rutinas de devolución de llamada de archivos de atributos en drivers/usb/core/sysfs.c, la función interface_authorized_store() es la única que adquiere un bloqueo de dispositivo en un dispositivo antecesor: llama a usb_deauthorize_interface(), que bloquea el dispositivo USB principal de la interfaz. Esto conducirá a un punto muerto si otro proceso ya posee ese bloqueo e intenta eliminar la interfaz, ya sea mediante un cambio de configuración o porque el dispositivo se ha desconectado. Como parte del procedimiento de eliminación, device_del() espera a que se completen todas las devoluciones de llamadas de atributos sysfs en curso. • https://git.kernel.org/stable/c/310d2b4124c073a2057ef9d952d4d938e9b1dfd9 https://git.kernel.org/stable/c/8cbdd324b41528994027128207fae8100dff094f https://git.kernel.org/stable/c/12d6a5681a0a5cecc2af7860f0a1613fa7c6e947 https://git.kernel.org/stable/c/e451709573f8be904a8a72d0775bf114d7c291d9 https://git.kernel.org/stable/c/1b175bc579f46520b11ecda443bcd2ee4904f66a https://git.kernel.org/stable/c/ab062fa3dc69aea88fe62162c5881ba14b50ecc5 https://git.kernel.org/stable/c/122a06f1068bf5e39089863f4f60b1f5d4273384 https://git.kernel.org/stable/c/dbdf66250d2d33e8b27352fcb901de79f • CWE-667: Improper Locking •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26931 – scsi: qla2xxx: Fix command flush on cable pull
https://notcve.org/view.php?id=CVE-2024-26931
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix command flush on cable pull System crash due to command failed to flush back to SCSI layer. BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 27 PID: 793455 Comm: kworker/u130:6 Kdump: loaded Tainted: G OE --------- - - 4.18.0-372.9.1.el8.x86_64 #1 Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021 Workqueue: nvme-wq nvme_fc_connect_ctrl_work [nvme_fc] RIP: 0010:__wake_up_common+0x4c/0x190 Code: 24 10 4d 85 c9 74 0a 41 f6 01 04 0f 85 9d 00 00 00 48 8b 43 08 48 83 c3 08 4c 8d 48 e8 49 8d 41 18 48 39 c3 0f 84 f0 00 00 00 <49> 8b 41 18 89 54 24 08 31 ed 4c 8d 70 e8 45 8b 29 41 f6 c5 04 75 RSP: 0018:ffff95f3e0cb7cd0 EFLAGS: 00010086 RAX: 0000000000000000 RBX: ffff8b08d3b26328 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8b08d3b26320 RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8 R10: 0000000000000000 R11: ffff95f3e0cb7a60 R12: ffff95f3e0cb7d20 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8b2fdf6c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000002f1e410002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: __wake_up_common_lock+0x7c/0xc0 qla_nvme_ls_req+0x355/0x4c0 [qla2xxx] qla2xxx [0000:12:00.1]-f084:3: qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae1407ca000 from port 21:32:00:02:ac:07:ee:b8 loop_id 0x02 s_id 01:02:00 logout 1 keep 0 els_logo 0 ? __nvme_fc_send_ls_req+0x260/0x380 [nvme_fc] qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:00:02:ac:07:ee:b8 state transitioned from ONLINE to LOST - portid=010200. ? nvme_fc_send_ls_req.constprop.42+0x1a/0x45 [nvme_fc] qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320002ac07eeb8. rport ffff8ae598122000 roles 1 ? nvme_fc_connect_ctrl_work.cold.63+0x1e3/0xa7d [nvme_fc] qla2xxx [0000:12:00.1]-f084:3: qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae14801e000 from port 21:32:01:02:ad:f7:ee:b8 loop_id 0x04 s_id 01:02:01 logout 1 keep 0 els_logo 0 ? __switch_to+0x10c/0x450 ? • https://git.kernel.org/stable/c/b73377124f56d2fec154737c2f8d2e839c237d5a https://git.kernel.org/stable/c/d7a68eee87b05d4e29419e6f151aef99314970a9 https://git.kernel.org/stable/c/67b2d35853c2da25a8ca1c4190a5e96d3083c2ac https://git.kernel.org/stable/c/a859f6a8f4234b8ef62862bf7a92f1af5f8cd47a https://git.kernel.org/stable/c/09c0ac18cac206ed1218b1fe6c1a0918e5ea9211 https://git.kernel.org/stable/c/8de1584ec4fe0ebea33c273036e7e0a05e65c81d https://git.kernel.org/stable/c/8f0d32004e3a572bb77e6c11c2797c87f8c9703d https://git.kernel.org/stable/c/ec7587eef003cab15a13446d67c3adb88 •
CVSS: 7.8EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26930 – scsi: qla2xxx: Fix double free of the ha->vp_map pointer
https://notcve.org/view.php?id=CVE-2024-26930
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix double free of the ha->vp_map pointer Coverity scan reported potential risk of double free of the pointer ha->vp_map. ha->vp_map was freed in qla2x00_mem_alloc(), and again freed in function qla2x00_mem_free(ha). Assign NULL to vp_map and kfree take care of NULL. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: qla2xxx: Corrección de doble liberación del puntero ha->vp_map Coverity scan informó un riesgo potencial de doble liberación del puntero ha->vp_map. ha->vp_map se liberó en qla2x00_mem_alloc() y nuevamente se liberó en la función qla2x00_mem_free(ha). Asigne NULL a vp_map y kfree se encargará de NULL. A vulnerability was found in the Linux kernel. • https://git.kernel.org/stable/c/f14cee7a882cb79528f17a2335f53e9fd1848467 https://git.kernel.org/stable/c/b7deb675d674f44e0ddbab87fee8f9f098925e73 https://git.kernel.org/stable/c/825d63164a2e6bacb059a9afb5605425b485413f https://git.kernel.org/stable/c/e288285d47784fdcf7c81be56df7d65c6f10c58b https://access.redhat.com/security/cve/CVE-2024-26930 https://bugzilla.redhat.com/show_bug.cgi?id=2278248 • CWE-415: Double Free •
CVSS: 7.8EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26929 – scsi: qla2xxx: Fix double free of fcport
https://notcve.org/view.php?id=CVE-2024-26929
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix double free of fcport The server was crashing after LOGO because fcport was getting freed twice. -----------[ cut here ]----------- kernel BUG at mm/slub.c:371! invalid opcode: 0000 1 SMP PTI CPU: 35 PID: 4610 Comm: bash Kdump: loaded Tainted: G OE --------- - - 4.18.0-425.3.1.el8.x86_64 #1 Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021 RIP: 0010:set_freepointer.part.57+0x0/0x10 RSP: 0018:ffffb07107027d90 EFLAGS: 00010246 RAX: ffff9cb7e3150000 RBX: ffff9cb7e332b9c0 RCX: ffff9cb7e3150400 RDX: 0000000000001f37 RSI: 0000000000000000 RDI: ffff9cb7c0005500 RBP: fffff693448c5400 R08: 0000000080000000 R09: 0000000000000009 R10: 0000000000000000 R11: 0000000000132af0 R12: ffff9cb7c0005500 R13: ffff9cb7e3150000 R14: ffffffffc06990e0 R15: ffff9cb7ea85ea58 FS: 00007ff6b79c2740(0000) GS:ffff9cb8f7ec0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055b426b7d700 CR3: 0000000169c18002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: kfree+0x238/0x250 qla2x00_els_dcmd_sp_free+0x20/0x230 [qla2xxx] ? qla24xx_els_dcmd_iocb+0x607/0x690 [qla2xxx] qla2x00_issue_logo+0x28c/0x2a0 [qla2xxx] ? qla2x00_issue_logo+0x28c/0x2a0 [qla2xxx] ? kernfs_fop_write+0x11e/0x1a0 Remove one of the free calls and add check for valid fcport. • https://git.kernel.org/stable/c/b03e626bd6d3f0684f56ee1890d70fc9ca991c04 https://git.kernel.org/stable/c/282877633b25d67021a34169c5b5519b1d4ef65e https://git.kernel.org/stable/c/f85af9f1aa5e2f53694a6cbe72010f754b5ff862 https://git.kernel.org/stable/c/9b43d2884b54d415caab48878b526dfe2ae9921b https://git.kernel.org/stable/c/846fb9f112f618ec6ae181d8dae7961652574774 https://git.kernel.org/stable/c/82f522ae0d97119a43da53e0f729275691b9c525 https://access.redhat.com/security/cve/CVE-2024-26929 https://bugzilla.redhat.com/show_bug.cgi?id=2278250 • CWE-415: Double Free •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2022-48664 – btrfs: fix hang during unmount when stopping a space reclaim worker
https://notcve.org/view.php?id=CVE-2022-48664
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix hang during unmount when stopping a space reclaim worker Often when running generic/562 from fstests we can hang during unmount, resulting in a trace like this: Sep 07 11:52:00 debian9 unknown: run fstests generic/562 at 2022-09-07 11:52:00 Sep 07 11:55:32 debian9 kernel: INFO: task umount:49438 blocked for more than 120 seconds. Sep 07 11:55:32 debian9 kernel: Not tainted 6.0.0-rc2-btrfs-next-122 #1 Sep 07 11:55:32 debian9 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Sep 07 11:55:32 debian9 kernel: task:umount state:D stack: 0 pid:49438 ppid: 25683 flags:0x00004000 Sep 07 11:55:32 debian9 kernel: Call Trace: Sep 07 11:55:32 debian9 kernel: <TASK> Sep 07 11:55:32 debian9 kernel: __schedule+0x3c8/0xec0 Sep 07 11:55:32 debian9 kernel: ? rcu_read_lock_sched_held+0x12/0x70 Sep 07 11:55:32 debian9 kernel: schedule+0x5d/0xf0 Sep 07 11:55:32 debian9 kernel: schedule_timeout+0xf1/0x130 Sep 07 11:55:32 debian9 kernel: ? lock_release+0x224/0x4a0 Sep 07 11:55:32 debian9 kernel: ? lock_acquired+0x1a0/0x420 Sep 07 11:55:32 debian9 kernel: ? trace_hardirqs_on+0x2c/0xd0 Sep 07 11:55:32 debian9 kernel: __wait_for_common+0xac/0x200 Sep 07 11:55:32 debian9 kernel: ? • https://git.kernel.org/stable/c/d6fd0ae25c6495674dc5a41a8d16bc8e0073276d https://git.kernel.org/stable/c/1ec2bf44c3770b9c3d510b1e78d50cd7fd19e8c5 https://git.kernel.org/stable/c/b4c7c826709b7d882ec9b264d5032e887e6bd720 https://git.kernel.org/stable/c/6ac5b52e3f352f9cb270c89e6e1d4dadb564ddb8 https://git.kernel.org/stable/c/d8a76a2e514fbbb315a6dfff2d342de2de833994 https://git.kernel.org/stable/c/c338bea1fec5504290dc0acf026c9e7dba25004b https://git.kernel.org/stable/c/a362bb864b8db4861977d00bd2c3222503ccc34b •