CVSS: 4.4EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52730 – mmc: sdio: fix possible resource leaks in some error paths
https://notcve.org/view.php?id=CVE-2023-52730
In the Linux kernel, the following vulnerability has been resolved: mmc: sdio: fix possible resource leaks in some error paths If sdio_add_func() or sdio_init_func() fails, sdio_remove_func() can not release the resources, because the sdio function is not presented in these two cases, it won't call of_node_put() or put_device(). To fix these leaks, make sdio_func_present() only control whether device_del() needs to be called or not, then always call of_node_put() and put_device(). In error case in sdio_init_func(), the reference of 'card->dev' is not get, to avoid redundant put in sdio_free_func_cis(), move the get_device() to sdio_alloc_func() and put_device() to sdio_release_func(), it can keep the get/put function be balanced. Without this patch, while doing fault inject test, it can get the following leak reports, after this fix, the leak is gone. unreferenced object 0xffff888112514000 (size 2048): comm "kworker/3:2", pid 65, jiffies 4294741614 (age 124.774s) hex dump (first 32 bytes): 00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 88 ff ff ..o.....`X...... 10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff .@Q......@Q..... backtrace: [<000000009e5931da>] kmalloc_trace+0x21/0x110 [<000000002f839ccb>] mmc_alloc_card+0x38/0xb0 [mmc_core] [<0000000004adcbf6>] mmc_sdio_init_card+0xde/0x170 [mmc_core] [<000000007538fea0>] mmc_attach_sdio+0xcb/0x1b0 [mmc_core] [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core] unreferenced object 0xffff888112511000 (size 2048): comm "kworker/3:2", pid 65, jiffies 4294741623 (age 124.766s) hex dump (first 32 bytes): 00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff .@Q......X...... 10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff ..Q.......Q..... backtrace: [<000000009e5931da>] kmalloc_trace+0x21/0x110 [<00000000fcbe706c>] sdio_alloc_func+0x35/0x100 [mmc_core] [<00000000c68f4b50>] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core] [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mmc: sdio: soluciona posibles fugas de recursos en algunas rutas de error. • https://git.kernel.org/stable/c/3d10a1ba0d37c8f5fd5afcdda00613fbb8a90bf5 https://git.kernel.org/stable/c/92ff03c2563c9b57a027c744750f3b7d2f261c58 https://git.kernel.org/stable/c/5c7858adada31dbed042448cff6997dd6efc472a https://git.kernel.org/stable/c/761db46b29b496946046d8cb33c7ea6de6bef36e https://git.kernel.org/stable/c/30716d9f0fa1766e522cf24c8a456244e4fc9931 https://git.kernel.org/stable/c/1e06cf04239e202248c8fa356bf11449dc73cfbd https://git.kernel.org/stable/c/f855d31bb38d663c3ba672345d7cce9324ba3b72 https://git.kernel.org/stable/c/605d9fb9556f8f5fb4566f4df1480f280 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52708 – mmc: mmc_spi: fix error handling in mmc_spi_probe()
https://notcve.org/view.php?id=CVE-2023-52708
In the Linux kernel, the following vulnerability has been resolved: mmc: mmc_spi: fix error handling in mmc_spi_probe() If mmc_add_host() fails, it doesn't need to call mmc_remove_host(), or it will cause null-ptr-deref, because of deleting a not added device in mmc_remove_host(). To fix this, goto label 'fail_glue_init', if mmc_add_host() fails, and change the label 'fail_add_host' to 'fail_gpiod_request'. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mmc: mmc_spi: corrige el manejo de errores en mmc_spi_probe(). Si mmc_add_host() falla, no es necesario llamar a mmc_remove_host(), o causará null-ptr-deref, debido a la eliminación de un dispositivo no agregado en mmc_remove_host(). Para solucionar este problema, vaya a la etiqueta 'fail_glue_init', si mmc_add_host() falla, y cambie la etiqueta 'fail_add_host' a 'fail_gpiod_request'. • https://git.kernel.org/stable/c/15a0580ced081a0f7dc2deea8a4812bdc5e9a109 https://git.kernel.org/stable/c/e9b488d60f51ae312006e224e03a30a151c28bdd https://git.kernel.org/stable/c/0b3edcb24bd81b3b2e3dac89f4733bfd47d283be https://git.kernel.org/stable/c/ecad2fafd424ffdc203b2748ded0b37e4bbecef3 https://git.kernel.org/stable/c/82645bf4ed02abe930a659c5fe16d593a6dbd93f https://git.kernel.org/stable/c/cf4c9d2ac1e42c7d18b921bec39486896645b714 •
CVSS: 7.0EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52707 – sched/psi: Fix use-after-free in ep_remove_wait_queue()
https://notcve.org/view.php?id=CVE-2023-52707
In the Linux kernel, the following vulnerability has been resolved: sched/psi: Fix use-after-free in ep_remove_wait_queue() If a non-root cgroup gets removed when there is a thread that registered trigger and is polling on a pressure file within the cgroup, the polling waitqueue gets freed in the following path: do_rmdir cgroup_rmdir kernfs_drain_open_files cgroup_file_release cgroup_pressure_release psi_trigger_destroy However, the polling thread still has a reference to the pressure file and will access the freed waitqueue when the file is closed or upon exit: fput ep_eventpoll_release ep_free ep_remove_wait_queue remove_wait_queue This results in use-after-free as pasted below. The fundamental problem here is that cgroup_file_release() (and consequently waitqueue's lifetime) is not tied to the file's real lifetime. Using wake_up_pollfree() here might be less than ideal, but it is in line with the comment at commit 42288cb44c4b ("wait: add wake_up_pollfree()") since the waitqueue's lifetime is not tied to file's one and can be considered as another special case. While this would be fixable by somehow making cgroup_file_release() be tied to the fput(), it would require sizable refactoring at cgroups or higher layer which might be more justifiable if we identify more cases like this. BUG: KASAN: use-after-free in _raw_spin_lock_irqsave+0x60/0xc0 Write of size 4 at addr ffff88810e625328 by task a.out/4404 CPU: 19 PID: 4404 Comm: a.out Not tainted 6.2.0-rc6 #38 Hardware name: Amazon EC2 c5a.8xlarge/, BIOS 1.0 10/16/2017 Call Trace: <TASK> dump_stack_lvl+0x73/0xa0 print_report+0x16c/0x4e0 kasan_report+0xc3/0xf0 kasan_check_range+0x2d2/0x310 _raw_spin_lock_irqsave+0x60/0xc0 remove_wait_queue+0x1a/0xa0 ep_free+0x12c/0x170 ep_eventpoll_release+0x26/0x30 __fput+0x202/0x400 task_work_run+0x11d/0x170 do_exit+0x495/0x1130 do_group_exit+0x100/0x100 get_signal+0xd67/0xde0 arch_do_signal_or_restart+0x2a/0x2b0 exit_to_user_mode_prepare+0x94/0x100 syscall_exit_to_user_mode+0x20/0x40 do_syscall_64+0x52/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> Allocated by task 4404: kasan_set_track+0x3d/0x60 __kasan_kmalloc+0x85/0x90 psi_trigger_create+0x113/0x3e0 pressure_write+0x146/0x2e0 cgroup_file_write+0x11c/0x250 kernfs_fop_write_iter+0x186/0x220 vfs_write+0x3d8/0x5c0 ksys_write+0x90/0x110 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Freed by task 4407: kasan_set_track+0x3d/0x60 kasan_save_free_info+0x27/0x40 ____kasan_slab_free+0x11d/0x170 slab_free_freelist_hook+0x87/0x150 __kmem_cache_free+0xcb/0x180 psi_trigger_destroy+0x2e8/0x310 cgroup_file_release+0x4f/0xb0 kernfs_drain_open_files+0x165/0x1f0 kernfs_drain+0x162/0x1a0 __kernfs_remove+0x1fb/0x310 kernfs_remove_by_name_ns+0x95/0xe0 cgroup_addrm_files+0x67f/0x700 cgroup_destroy_locked+0x283/0x3c0 cgroup_rmdir+0x29/0x100 kernfs_iop_rmdir+0xd1/0x140 vfs_rmdir+0xfe/0x240 do_rmdir+0x13d/0x280 __x64_sys_rmdir+0x2c/0x30 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sched/psi: corrige el use after free en ep_remove_wait_queue() si se elimina un cgroup no raíz cuando hay un subproceso que registró un activador y está sondeando un archivo de presión dentro en cgroup, la cola de espera de sondeo se libera en la siguiente ruta: do_rmdir cgroup_rmdir kernfs_drain_open_files cgroup_file_release cgroup_pression_release psi_trigger_destroy Sin embargo, el hilo de sondeo aún tiene una referencia al archivo de presión y accederá a la cola de espera liberada cuando el archivo se cierre o al salir: fput ep_eventpoll_release ep_free ep_remove_wait_queue remove_wait_queue Esto da como resultado un use after free como se pega a continuación. El problema fundamental aquí es que cgroup_file_release() (y en consecuencia la vida útil de la cola de espera) no está ligada a la vida real del archivo. Usar wake_up_pollfree() aquí puede no ser ideal, pero está en línea con el comentario en la confirmación 42288cb44c4b ("espera: agregar wake_up_pollfree()") ya que la vida útil de la cola de espera no está ligada a la del archivo y puede considerarse como otro caso especial. . Si bien esto se podría solucionar haciendo que cgroup_file_release() esté vinculado de alguna manera a fput(), requeriría una refactorización considerable en cgroups o en una capa superior, lo que podría ser más justificable si identificamos más casos como este. • https://git.kernel.org/stable/c/0e94682b73bfa6c44c98af7a26771c9c08c055d5 https://git.kernel.org/stable/c/7caeb5457bd01ccba0df1d6f4872f20d28e50b38 https://git.kernel.org/stable/c/ec9c7aa08819f976b2492fa63c41b5712d2924b5 https://git.kernel.org/stable/c/cca2b3feb70170ef6f0fbc4b4d91eea235a2b73a https://git.kernel.org/stable/c/c6879a4dcefe92d870ab68cabaa9caeda4f2af5a https://git.kernel.org/stable/c/c2dbe32d5db5c4ead121cf86dabd5ab691fb47fe https://access.redhat.com/security/cve/CVE-2023-52707 https://bugzilla.redhat.com/show_bug.cgi?id=2282615 • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52705 – nilfs2: fix underflow in second superblock position calculations
https://notcve.org/view.php?id=CVE-2023-52705
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix underflow in second superblock position calculations Macro NILFS_SB2_OFFSET_BYTES, which computes the position of the second superblock, underflows when the argument device size is less than 4096 bytes. Therefore, when using this macro, it is necessary to check in advance that the device size is not less than a lower limit, or at least that underflow does not occur. The current nilfs2 implementation lacks this check, causing out-of-bound block access when mounting devices smaller than 4096 bytes: I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 NILFS (loop0): unable to read secondary superblock (blocksize = 1024) In addition, when trying to resize the filesystem to a size below 4096 bytes, this underflow occurs in nilfs_resize_fs(), passing a huge number of segments to nilfs_sufile_resize(), corrupting parameters such as the number of segments in superblocks. This causes excessive loop iterations in nilfs_sufile_resize() during a subsequent resize ioctl, causing semaphore ns_segctor_sem to block for a long time and hang the writer thread: INFO: task segctord:5067 blocked for more than 143 seconds. Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:segctord state:D stack:23456 pid:5067 ppid:2 flags:0x00004000 Call Trace: <TASK> context_switch kernel/sched/core.c:5293 [inline] __schedule+0x1409/0x43f0 kernel/sched/core.c:6606 schedule+0xc3/0x190 kernel/sched/core.c:6682 rwsem_down_write_slowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190 nilfs_transaction_lock+0x25c/0x4f0 fs/nilfs2/segment.c:357 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2486 [inline] nilfs_segctor_thread+0x52f/0x1140 fs/nilfs2/segment.c:2570 kthread+0x270/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 </TASK> ... Call Trace: <TASK> folio_mark_accessed+0x51c/0xf00 mm/swap.c:515 __nilfs_get_page_block fs/nilfs2/page.c:42 [inline] nilfs_grab_buffer+0x3d3/0x540 fs/nilfs2/page.c:61 nilfs_mdt_submit_block+0xd7/0x8f0 fs/nilfs2/mdt.c:121 nilfs_mdt_read_block+0xeb/0x430 fs/nilfs2/mdt.c:176 nilfs_mdt_get_block+0x12d/0xbb0 fs/nilfs2/mdt.c:251 nilfs_sufile_get_segment_usage_block fs/nilfs2/sufile.c:92 [inline] nilfs_sufile_truncate_range fs/nilfs2/sufile.c:679 [inline] nilfs_sufile_resize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777 nilfs_resize_fs+0x20c/0xed0 fs/nilfs2/super.c:422 nilfs_ioctl_resize fs/nilfs2/ioctl.c:1033 [inline] nilfs_ioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301 ... This fixes these issues by inserting appropriate minimum device size checks or anti-underflow checks, depending on where the macro is used. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: corrige el desbordamiento en los cálculos de la posición del segundo superbloque. La macro NILFS_SB2_OFFSET_BYTES, que calcula la posición del segundo superbloque, sufre un desbordamiento cuando el tamaño del dispositivo del argumento es inferior a 4096 bytes. • https://git.kernel.org/stable/c/2f7a1135b202977b82457adde7db6c390056863b https://git.kernel.org/stable/c/b96591e2c35c8b47db0ec816b5fc6cb8868000ff https://git.kernel.org/stable/c/52844d8382cd9166d708032def8905ffc3ae550f https://git.kernel.org/stable/c/0ee5ed0126a2211f7174492da2ca2c29f43755c5 https://git.kernel.org/stable/c/a158782b56b070485d54d25fc9aaf2c8f3752205 https://git.kernel.org/stable/c/a8ef5109f93cea9933bbac0455d8c18757b3fcb4 https://git.kernel.org/stable/c/99b9402a36f0799f25feee4465bfa4b8dfa74b4d •
CVSS: 3.3EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52703 – net/usb: kalmia: Don't pass act_len in usb_bulk_msg error path
https://notcve.org/view.php?id=CVE-2023-52703
In the Linux kernel, the following vulnerability has been resolved: net/usb: kalmia: Don't pass act_len in usb_bulk_msg error path syzbot reported that act_len in kalmia_send_init_packet() is uninitialized when passing it to the first usb_bulk_msg error path. Jiri Pirko noted that it's pointless to pass it in the error path, and that the value that would be printed in the second error path would be the value of act_len from the first call to usb_bulk_msg.[1] With this in mind, let's just not pass act_len to the usb_bulk_msg error paths. 1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/ En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/usb: kalmia: No pasar act_len en la ruta de error usb_bulk_msg syzbot informó que act_len en kalmia_send_init_packet() no está inicializado al pasarlo a la primera ruta de error usb_bulk_msg. Jiri Pirko señaló que no tiene sentido pasarlo en la ruta de error y que el valor que se imprimiría en la segunda ruta de error sería el valor de act_len de la primera llamada a usb_bulk_msg.[1] Con esto en mente, simplemente no pasemos act_len a las rutas de error usb_bulk_msg. 1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/ • https://git.kernel.org/stable/c/d40261236e8e278cb1936cb5e934262971692b10 https://git.kernel.org/stable/c/1b5de7d44890b78519acbcc80d8d1f23ff2872e5 https://git.kernel.org/stable/c/723ef7b66f37c0841f5a451ccbce47ee1641e081 https://git.kernel.org/stable/c/a753352622b4f3c0219e0e9c73114b2848ae6042 https://git.kernel.org/stable/c/525bdcb0838d19d918c7786151ee14661967a030 https://git.kernel.org/stable/c/338f826d3afead6e4df521f7972a4bef04a72efb https://git.kernel.org/stable/c/02df3170c04a8356cd571ab9155a42f030190abc https://git.kernel.org/stable/c/c68f345b7c425b38656e1791a0486769a • CWE-15: External Control of System or Configuration Setting •