CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52622 – ext4: avoid online resizing failures due to oversized flex bg
https://notcve.org/view.php?id=CVE-2023-52622
In the Linux kernel, the following vulnerability has been resolved: ext4: avoid online resizing failures due to oversized flex bg When we online resize an ext4 filesystem with a oversized flexbg_size, mkfs.ext4 -F -G 67108864 $dev -b 4096 100M mount $dev $dir resize2fs $dev 16G the following WARN_ON is triggered: ================================================================== WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550 Modules linked in: sg(E) CPU: 0 PID: 427 Comm: resize2fs Tainted: G E 6.6.0-rc5+ #314 RIP: 0010:__alloc_pages+0x411/0x550 Call Trace: <TASK> __kmalloc_large_node+0xa2/0x200 __kmalloc+0x16e/0x290 ext4_resize_fs+0x481/0xd80 __ext4_ioctl+0x1616/0x1d90 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0xf0/0x150 do_syscall_64+0x3b/0x90 ================================================================== This is because flexbg_size is too large and the size of the new_group_data array to be allocated exceeds MAX_ORDER. Currently, the minimum value of MAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the corresponding maximum number of groups that can be allocated is: (PAGE_SIZE << MAX_ORDER) / sizeof(struct ext4_new_group_data) ≈ 21845 And the value that is down-aligned to the power of 2 is 16384. Therefore, this value is defined as MAX_RESIZE_BG, and the number of groups added each time does not exceed this value during resizing, and is added multiple times to complete the online resizing. The difference is that the metadata in a flex_bg may be more dispersed. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: evita fallos de cambio de tamaño en línea debido a flex bg sobredimensionado Cuando redimensionamos en línea un sistema de archivos ext4 con un flexbg_size sobredimensionado, mkfs.ext4 -F -G 67108864 $dev -b 4096 100M mount $dev $dir resize2fs $dev 16G se activa el siguiente WARN_ON: ===================================== ============================== ADVERTENCIA: CPU: 0 PID: 427 en mm/page_alloc.c:4402 __alloc_pages+0x411/ 0x550 Módulos vinculados en: sg(E) CPU: 0 PID: 427 Comm: resize2fs Contaminado: GE 6.6.0-rc5+ #314 RIP: 0010:__alloc_pages+0x411/0x550 Seguimiento de llamadas: __kmalloc_large_node+0xa2/0x200 __kmalloc+ 0x16e/0x290 text4_resize_fs+0x481/0xd80 __ext4_ioctl+0x1616/0x1d90 text4_ioctl+0x12/0x20 __x64_sys_ioctl+0xf0/0x150 do_syscall_64+0x3b/0x90 ======== =============== ============================================ Esto se debe a que flexbg_size también lo es grande y el tamaño de la matriz new_group_data que se asignará excede MAX_ORDER. • https://git.kernel.org/stable/c/cd1f93ca97a9136989f3bd2bf90696732a2ed644 https://git.kernel.org/stable/c/b183fe8702e78bba3dcef8e7193cab6898abee07 https://git.kernel.org/stable/c/cfbbb3199e71b63fc26cee0ebff327c47128a1e8 https://git.kernel.org/stable/c/d76c8d7ffe163c6bf2f1ef680b0539c2b3902b90 https://git.kernel.org/stable/c/6d2cbf517dcabc093159cf138ad5712c9c7fa954 https://git.kernel.org/stable/c/8b1413dbfe49646eda2c00c0f1144ee9d3368e0c https://git.kernel.org/stable/c/dc3e0f55bec4410f3d74352c4a7c79f518088ee2 https://git.kernel.org/stable/c/5d1935ac02ca5aee364a449a35e2977ea • CWE-131: Incorrect Calculation of Buffer Size •
CVSS: 4.4EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52621 – bpf: Check rcu_read_lock_trace_held() before calling bpf map helpers
https://notcve.org/view.php?id=CVE-2023-52621
In the Linux kernel, the following vulnerability has been resolved: bpf: Check rcu_read_lock_trace_held() before calling bpf map helpers These three bpf_map_{lookup,update,delete}_elem() helpers are also available for sleepable bpf program, so add the corresponding lock assertion for sleepable bpf program, otherwise the following warning will be reported when a sleepable bpf program manipulates bpf map under interpreter mode (aka bpf_jit_enable=0): WARNING: CPU: 3 PID: 4985 at kernel/bpf/helpers.c:40 ...... CPU: 3 PID: 4985 Comm: test_progs Not tainted 6.6.0+ #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:bpf_map_lookup_elem+0x54/0x60 ...... Call Trace: <TASK> ? __warn+0xa5/0x240 ? bpf_map_lookup_elem+0x54/0x60 ? report_bug+0x1ba/0x1f0 ? handle_bug+0x40/0x80 ? • https://git.kernel.org/stable/c/d6d6fe4bb105595118f12abeed4a7bdd450853f3 https://git.kernel.org/stable/c/483cb92334cd7f1d5387dccc0ab5d595d27a669d https://git.kernel.org/stable/c/c7f1b6146f4a46d727c0d046284c28b6882c6304 https://git.kernel.org/stable/c/169410eba271afc9f0fb476d996795aa26770c6d https://access.redhat.com/security/cve/CVE-2023-52621 https://bugzilla.redhat.com/show_bug.cgi?id=2271690 • CWE-413: Improper Resource Locking •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26644 – btrfs: don't abort filesystem when attempting to snapshot deleted subvolume
https://notcve.org/view.php?id=CVE-2024-26644
In the Linux kernel, the following vulnerability has been resolved: btrfs: don't abort filesystem when attempting to snapshot deleted subvolume If the source file descriptor to the snapshot ioctl refers to a deleted subvolume, we get the following abort: BTRFS: Transaction aborted (error -2) WARNING: CPU: 0 PID: 833 at fs/btrfs/transaction.c:1875 create_pending_snapshot+0x1040/0x1190 [btrfs] Modules linked in: pata_acpi btrfs ata_piix libata scsi_mod virtio_net blake2b_generic xor net_failover virtio_rng failover scsi_common rng_core raid6_pq libcrc32c CPU: 0 PID: 833 Comm: t_snapshot_dele Not tainted 6.7.0-rc6 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014 RIP: 0010:create_pending_snapshot+0x1040/0x1190 [btrfs] RSP: 0018:ffffa09c01337af8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff9982053e7c78 RCX: 0000000000000027 RDX: ffff99827dc20848 RSI: 0000000000000001 RDI: ffff99827dc20840 RBP: ffffa09c01337c00 R08: 0000000000000000 R09: ffffa09c01337998 R10: 0000000000000003 R11: ffffffffb96da248 R12: fffffffffffffffe R13: ffff99820535bb28 R14: ffff99820b7bd000 R15: ffff99820381ea80 FS: 00007fe20aadabc0(0000) GS:ffff99827dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000559a120b502f CR3: 00000000055b6000 CR4: 00000000000006f0 Call Trace: <TASK> ? create_pending_snapshot+0x1040/0x1190 [btrfs] ? __warn+0x81/0x130 ? create_pending_snapshot+0x1040/0x1190 [btrfs] ? report_bug+0x171/0x1a0 ? • https://git.kernel.org/stable/c/2bdf872bcfe629a6202ffd6641615a8ed00e8464 https://git.kernel.org/stable/c/0877497dc97834728e1b528ddf1e1c484292c29c https://git.kernel.org/stable/c/6e6bca99e8d88d989a7cde4c064abea552d5219b https://git.kernel.org/stable/c/ec794a7528199e1be6d47bec03f4755aa75df256 https://git.kernel.org/stable/c/d8680b722f0ff6d7a01ddacc1844e0d52354d6ff https://git.kernel.org/stable/c/7081929ab2572920e94d70be3d332e5c9f97095a https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47173 – misc/uss720: fix memory leak in uss720_probe
https://notcve.org/view.php?id=CVE-2021-47173
In the Linux kernel, the following vulnerability has been resolved: misc/uss720: fix memory leak in uss720_probe uss720_probe forgets to decrease the refcount of usbdev in uss720_probe. Fix this by decreasing the refcount of usbdev by usb_put_dev. BUG: memory leak unreferenced object 0xffff888101113800 (size 2048): comm "kworker/0:1", pid 7, jiffies 4294956777 (age 28.870s) hex dump (first 32 bytes): ff ff ff ff 31 00 00 00 00 00 00 00 00 00 00 00 ....1........... 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 ................ backtrace: [<ffffffff82b8e822>] kmalloc include/linux/slab.h:554 [inline] [<ffffffff82b8e822>] kzalloc include/linux/slab.h:684 [inline] [<ffffffff82b8e822>] usb_alloc_dev+0x32/0x450 drivers/usb/core/usb.c:582 [<ffffffff82b98441>] hub_port_connect drivers/usb/core/hub.c:5129 [inline] [<ffffffff82b98441>] hub_port_connect_change drivers/usb/core/hub.c:5363 [inline] [<ffffffff82b98441>] port_event drivers/usb/core/hub.c:5509 [inline] [<ffffffff82b98441>] hub_event+0x1171/0x20c0 drivers/usb/core/hub.c:5591 [<ffffffff81259229>] process_one_work+0x2c9/0x600 kernel/workqueue.c:2275 [<ffffffff81259b19>] worker_thread+0x59/0x5d0 kernel/workqueue.c:2421 [<ffffffff81261228>] kthread+0x178/0x1b0 kernel/kthread.c:292 [<ffffffff8100227f>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc/uss720: corrige la pérdida de memoria en uss720_probe uss720_probe olvida disminuir el recuento de usbdev en uss720_probe. Solucione este problema disminuyendo el recuento de usbdev por usb_put_dev. ERROR: pérdida de memoria, objeto sin referencia 0xffff888101113800 (tamaño 2048): comunicación "kworker/0:1", pid 7, jiffies 4294956777 (edad 28,870 s) volcado hexadecimal (primeros 32 bytes): ff ff ff ff 31 00 00 00 00 00 00 00 00 00 00 00 ....1.......... 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 ................. ... seguimiento: [] kmalloc include/linux/slab.h:554 [en línea] [] kzalloc include/linux/slab.h:684 [en línea] [] usb_alloc_dev+0x32/ 0x450 controladores/usb/core/usb.c:582 [] hub_port_connect drivers/usb/core/hub.c:5129 [en línea] [] hub_port_connect_change drivers/usb/core/hub.c:5363 [ en línea] [] port_event drivers/usb/core/hub.c:5509 [en línea] [] hub_event+0x1171/0x20c0 drivers/usb/core/hub.c:5591 [] Process_one_work+ 0x2c9/0x600 kernel/workqueue.c:2275 [] trabajador_thread+0x59/0x5d0 kernel/workqueue.c:2421 [] kthread+0x178/0x1b0 kernel/kthread.c:292 [ ] ret_from_fork +0x1f/0x30 arco/x86/entrada/entrada_64.S:294 • https://git.kernel.org/stable/c/0f36163d3abefbda1b21a330b3fdf3c2dc076d94 https://git.kernel.org/stable/c/5f46b2410db2c8f26b8bb91b40deebf4ec184391 https://git.kernel.org/stable/c/7889c70e6173ef358f3cd7578db127a489035a42 https://git.kernel.org/stable/c/bcb30cc8f8befcbdbcf7a016e4dfd4747c54a364 https://git.kernel.org/stable/c/386918878ce4cd676e4607233866e03c9399a46a https://git.kernel.org/stable/c/36b5ff1db1a4ef4fdbc2bae364344279f033ad88 https://git.kernel.org/stable/c/5394ae9d8c7961dd93807fdf1b12a1dde96b0a55 https://git.kernel.org/stable/c/a3c3face38cb49932c62adcc1289914f1 • CWE-401: Missing Release of Memory after Effective Lifetime •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47170 – USB: usbfs: Don't WARN about excessively large memory allocations
https://notcve.org/view.php?id=CVE-2021-47170
In the Linux kernel, the following vulnerability has been resolved: USB: usbfs: Don't WARN about excessively large memory allocations Syzbot found that the kernel generates a WARNing if the user tries to submit a bulk transfer through usbfs with a buffer that is way too large. This isn't a bug in the kernel; it's merely an invalid request from the user and the usbfs code does handle it correctly. In theory the same thing can happen with async transfers, or with the packet descriptor table for isochronous transfers. To prevent the MM subsystem from complaining about these bad allocation requests, add the __GFP_NOWARN flag to the kmalloc calls for these buffers. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: usbfs: No ADVERTIR sobre asignaciones de memoria excesivamente grandes. Syzbot descubrió que el kernel genera una ADVERTENCIA si el usuario intenta enviar una transferencia masiva a través de usbfs con un búfer demasiado grande. Esto no es un error en el kernel; es simplemente una solicitud no válida del usuario y el código usbfs la maneja correctamente. • https://git.kernel.org/stable/c/2ab21d6e1411999b5fb43434f421f00bf50002eb https://git.kernel.org/stable/c/2c835fede13e03f2743a333e4370b5ed2db91e83 https://git.kernel.org/stable/c/8d83f109e920d2776991fa142bb904d985dca2ed https://git.kernel.org/stable/c/9f7cb3f01a10d9064cf13b3d26fb7e7a5827d098 https://git.kernel.org/stable/c/4f2629ea67e7225c3fd292c7fe4f5b3c9d6392de •