CVSS: 4.4EPSS: 0%CPEs: 4EXPL: 0CVE-2024-38604 – block: refine the EOF check in blkdev_iomap_begin
https://notcve.org/view.php?id=CVE-2024-38604
In the Linux kernel, the following vulnerability has been resolved: block: refine the EOF check in blkdev_iomap_begin blkdev_iomap_begin rounds down the offset to the logical block size before stashing it in iomap->offset and checking that it still is inside the inode size. Check the i_size check to the raw pos value so that we don't try a zero size write if iter->pos is unaligned. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: refina la comprobación de EOF en blkdev_iomap_begin blkdev_iomap_begin redondea hacia abajo el desplazamiento al tamaño del bloque lógico antes de guardarlo en iomap->offset y comprobar que todavía está dentro del tamaño del inodo. Verifique la verificación i_size en el valor pos sin formato para que no intentemos una escritura de tamaño cero si iter->pos no está alineado. • https://git.kernel.org/stable/c/487c607df790d366e67a7d6a30adf785cdd98e55 https://git.kernel.org/stable/c/910717920c8c3f9386277a44c44d448058a18084 https://git.kernel.org/stable/c/72c54e063c32aeb38d43a2bd897821e6e5a1757d https://git.kernel.org/stable/c/10b723bcba8986537a484aa94dbfc9093fd776a1 https://git.kernel.org/stable/c/0c12028aec837f5a002009bbf68d179d506510e8 https://access.redhat.com/security/cve/CVE-2024-38604 https://bugzilla.redhat.com/show_bug.cgi?id=2293361 • CWE-20: Improper Input Validation •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-38603 – drivers/perf: hisi: hns3: Actually use devm_add_action_or_reset()
https://notcve.org/view.php?id=CVE-2024-38603
In the Linux kernel, the following vulnerability has been resolved: drivers/perf: hisi: hns3: Actually use devm_add_action_or_reset() pci_alloc_irq_vectors() allocates an irq vector. When devm_add_action() fails, the irq vector is not freed, which leads to a memory leak. Replace the devm_add_action with devm_add_action_or_reset to ensure the irq vector can be destroyed when it fails. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers/perf: hisi: hns3: en realidad usa devm_add_action_or_reset() pci_alloc_irq_vectors() asigna un vector irq. Cuando devm_add_action() falla, el vector irq no se libera, lo que provoca una pérdida de memoria. Reemplace devm_add_action con devm_add_action_or_reset para garantizar que el vector irq pueda destruirse cuando falla. • https://git.kernel.org/stable/c/66637ab137b44914356a9dc7a9b3f8ebcf0b0695 https://git.kernel.org/stable/c/1491a01ef5a98149048b12e208f6ed8e86ad10b9 https://git.kernel.org/stable/c/a7678a16c25b6ece1667ac681e3e783ff3de7a6f https://git.kernel.org/stable/c/2fcffaaf529d5fe3fdc6c0ee65a6f266b74de782 https://git.kernel.org/stable/c/b1e86f1ef8fa796f8935be392457639f3a907d91 https://git.kernel.org/stable/c/582c1aeee0a9e73010cf1c4cef338709860deeb0 •
CVSS: -EPSS: 0%CPEs: 10EXPL: 0CVE-2024-38602 – ax25: Fix reference count leak issues of ax25_dev
https://notcve.org/view.php?id=CVE-2024-38602
In the Linux kernel, the following vulnerability has been resolved: ax25: Fix reference count leak issues of ax25_dev The ax25_addr_ax25dev() and ax25_dev_device_down() exist a reference count leak issue of the object "ax25_dev". Memory leak issue in ax25_addr_ax25dev(): The reference count of the object "ax25_dev" can be increased multiple times in ax25_addr_ax25dev(). This will cause a memory leak. Memory leak issues in ax25_dev_device_down(): The reference count of ax25_dev is set to 1 in ax25_dev_device_up() and then increase the reference count when ax25_dev is added to ax25_dev_list. As a result, the reference count of ax25_dev is 2. But when the device is shutting down. The ax25_dev_device_down() drops the reference count once or twice depending on if we goto unlock_put or not, which will cause memory leak. As for the issue of ax25_addr_ax25dev(), it is impossible for one pointer to be on a list twice. So add a break in ax25_addr_ax25dev(). • https://git.kernel.org/stable/c/d01ffb9eee4af165d83b08dd73ebdf9fe94a519b https://git.kernel.org/stable/c/ef0a2a0565727a48f2e36a2c461f8b1e3a61922d https://git.kernel.org/stable/c/e2b558fe507a1ed4c43db2b0057fc6e41f20a14c https://git.kernel.org/stable/c/418993bbaafb0cd48f904ba68eeda052d624c821 https://git.kernel.org/stable/c/5ea00fc60676c0eebfa8560ec461209d638bca9d https://git.kernel.org/stable/c/9af0fd5c4453a44c692be0cbb3724859b75d739b https://git.kernel.org/stable/c/ae467750a3765dd1092eb29f58247950a2f9b60c https://git.kernel.org/stable/c/38eb01edfdaa1562fa00429be2e33f453 •
CVSS: 4.1EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38601 – ring-buffer: Fix a race between readers and resize checks
https://notcve.org/view.php?id=CVE-2024-38601
In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix a race between readers and resize checks The reader code in rb_get_reader_page() swaps a new reader page into the ring buffer by doing cmpxchg on old->list.prev->next to point it to the new page. Following that, if the operation is successful, old->list.next->prev gets updated too. This means the underlying doubly-linked list is temporarily inconsistent, page->prev->next or page->next->prev might not be equal back to page for some page in the ring buffer. The resize operation in ring_buffer_resize() can be invoked in parallel. It calls rb_check_pages() which can detect the described inconsistency and stop further tracing: [ 190.271762] ------------[ cut here ]------------ [ 190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0 [ 190.271789] Modules linked in: [...] [ 190.271991] Unloaded tainted modules: intel_uncore_frequency(E):1 skx_edac(E):1 [ 190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G E 6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f [ 190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014 [ 190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0 [ 190.272023] Code: [...] [ 190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206 [ 190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80 [ 190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700 [ 190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000 [ 190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720 [ 190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000 [ 190.272053] FS: 00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000 [ 190.272057] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0 [ 190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 190.272077] Call Trace: [ 190.272098] <TASK> [ 190.272189] ring_buffer_resize+0x2ab/0x460 [ 190.272199] __tracing_resize_ring_buffer.part.0+0x23/0xa0 [ 190.272206] tracing_resize_ring_buffer+0x65/0x90 [ 190.272216] tracing_entries_write+0x74/0xc0 [ 190.272225] vfs_write+0xf5/0x420 [ 190.272248] ksys_write+0x67/0xe0 [ 190.272256] do_syscall_64+0x82/0x170 [ 190.272363] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 190.272373] RIP: 0033:0x7f1bd657d263 [ 190.272381] Code: [...] [ 190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263 [ 190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001 [ 190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000 [ 190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500 [ 190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002 [ 190.272412] </TASK> [ 190.272414] ---[ end trace 0000000000000000 ]--- Note that ring_buffer_resize() calls rb_check_pages() only if the parent trace_buffer has recording disabled. Recent commit d78ab792705c ("tracing: Stop current tracer when resizing buffer") causes that it is now always the case which makes it more likely to experience this issue. The window to hit this race is nonetheless very small. To help reproducing it, one can add a delay loop in rb_get_reader_page(): ret = rb_head_page_replace(reader, cpu_buffer->reader_page); if (! • https://git.kernel.org/stable/c/659f451ff21315ebfeeb46b9adccee8ce1b52c25 https://git.kernel.org/stable/c/b50932ea673b5a089a4bb570a8a868d95c72854e https://git.kernel.org/stable/c/c68b7a442ee61d04ca58b2b5cb5ea7cb8230f84a https://git.kernel.org/stable/c/1e160196042cac946798ac192a0bc3398f1aa66b https://git.kernel.org/stable/c/595363182f28786d641666a09e674b852c83b4bb https://git.kernel.org/stable/c/54c64967ba5f8658ae7da76005024ebd3d9d8f6e https://git.kernel.org/stable/c/af3274905b3143ea23142bbf77bd9b610c54e533 https://git.kernel.org/stable/c/5ef9e330406d3fb4f4b2c8bca2c6b8a93 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: 4.4EPSS: 0%CPEs: 6EXPL: 0CVE-2024-38600 – ALSA: Fix deadlocks with kctl removals at disconnection
https://notcve.org/view.php?id=CVE-2024-38600
In the Linux kernel, the following vulnerability has been resolved: ALSA: Fix deadlocks with kctl removals at disconnection In snd_card_disconnect(), we set card->shutdown flag at the beginning, call callbacks and do sync for card->power_ref_sleep waiters at the end. The callback may delete a kctl element, and this can lead to a deadlock when the device was in the suspended state. Namely: * A process waits for the power up at snd_power_ref_and_wait() in snd_ctl_info() or read/write() inside card->controls_rwsem. * The system gets disconnected meanwhile, and the driver tries to delete a kctl via snd_ctl_remove*(); it tries to take card->controls_rwsem again, but this is already locked by the above. Since the sleeper isn't woken up, this deadlocks. An easy fix is to wake up sleepers before processing the driver disconnect callbacks but right after setting the card->shutdown flag. Then all sleepers will abort immediately, and the code flows again. So, basically this patch moves the wait_event() call at the right timing. While we're at it, just to be sure, call wait_event_all() instead of wait_event(), although we don't use exclusive events on this queue for now. • https://git.kernel.org/stable/c/ff80185e7b7b547a0911fcfc8aefc61c3e8304d7 https://git.kernel.org/stable/c/c2fb439f4f1425a961d20bec818fed2c2d9ef70a https://git.kernel.org/stable/c/2f103287ef7960854808930499d1181bd0145d68 https://git.kernel.org/stable/c/88ce3fe255d58a93624b467af036dc3519f309c7 https://git.kernel.org/stable/c/6b55e879e7bd023a03888fc6c8339edf82f576f4 https://git.kernel.org/stable/c/87988a534d8e12f2e6fc01fe63e6c1925dc5307c https://access.redhat.com/security/cve/CVE-2024-38600 https://bugzilla.redhat.com/show_bug.cgi?id=2293365 • CWE-833: Deadlock •