CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2023-52737 – btrfs: lock the inode in shared mode before starting fiemap
https://notcve.org/view.php?id=CVE-2023-52737
In the Linux kernel, the following vulnerability has been resolved: btrfs: lock the inode in shared mode before starting fiemap Currently fiemap does not take the inode's lock (VFS lock), it only locks a file range in the inode's io tree. This however can lead to a deadlock if we have a concurrent fsync on the file and fiemap code triggers a fault when accessing the user space buffer with fiemap_fill_next_extent(). The deadlock happens on the inode's i_mmap_lock semaphore, which is taken both by fsync and btrfs_page_mkwrite(). This deadlock was recently reported by syzbot and triggers a trace like the following: task:syz-executor361 state:D stack:20264 pid:5668 ppid:5119 flags:0x00004004 Call Trace: <TASK> context_switch kernel/sched/core.c:5293 [inline] __schedule+0x995/0xe20 kernel/sched/core.c:6606 schedule+0xcb/0x190 kernel/sched/core.c:6682 wait_on_state fs/btrfs/extent-io-tree.c:707 [inline] wait_extent_bit+0x577/0x6f0 fs/btrfs/extent-io-tree.c:751 lock_extent+0x1c2/0x280 fs/btrfs/extent-io-tree.c:1742 find_lock_delalloc_range+0x4e6/0x9c0 fs/btrfs/extent_io.c:488 writepage_delalloc+0x1ef/0x540 fs/btrfs/extent_io.c:1863 __extent_writepage+0x736/0x14e0 fs/btrfs/extent_io.c:2174 extent_write_cache_pages+0x983/0x1220 fs/btrfs/extent_io.c:3091 extent_writepages+0x219/0x540 fs/btrfs/extent_io.c:3211 do_writepages+0x3c3/0x680 mm/page-writeback.c:2581 filemap_fdatawrite_wbc+0x11e/0x170 mm/filemap.c:388 __filemap_fdatawrite_range mm/filemap.c:421 [inline] filemap_fdatawrite_range+0x175/0x200 mm/filemap.c:439 btrfs_fdatawrite_range fs/btrfs/file.c:3850 [inline] start_ordered_ops fs/btrfs/file.c:1737 [inline] btrfs_sync_file+0x4ff/0x1190 fs/btrfs/file.c:1839 generic_write_sync include/linux/fs.h:2885 [inline] btrfs_do_write_iter+0xcd3/0x1280 fs/btrfs/file.c:1684 call_write_iter include/linux/fs.h:2189 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f7d4054e9b9 RSP: 002b:00007f7d404fa2f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f7d405d87a0 RCX: 00007f7d4054e9b9 RDX: 0000000000000090 RSI: 0000000020000000 RDI: 0000000000000006 RBP: 00007f7d405a51d0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 61635f65646f6e69 R13: 65646f7475616f6e R14: 7261637369646f6e R15: 00007f7d405d87a8 </TASK> INFO: task syz-executor361:5697 blocked for more than 145 seconds. Not tainted 6.2.0-rc3-syzkaller-00376-g7c6984405241 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz-executor361 state:D stack:21216 pid:5697 ppid:5119 flags:0x00004004 Call Trace: <TASK> context_switch kernel/sched/core.c:5293 [inline] __schedule+0x995/0xe20 kernel/sched/core.c:6606 schedule+0xcb/0x190 kernel/sched/core.c:6682 rwsem_down_read_slowpath+0x5f9/0x930 kernel/locking/rwsem.c:1095 __down_read_common+0x54/0x2a0 kernel/locking/rwsem.c:1260 btrfs_page_mkwrite+0x417/0xc80 fs/btrfs/inode.c:8526 do_page_mkwrite+0x19e/0x5e0 mm/memory.c:2947 wp_page_shared+0x15e/0x380 mm/memory.c:3295 handle_pte_fault mm/memory.c:4949 [inline] __handle_mm_fault mm/memory.c:5073 [inline] handle_mm_fault+0x1b79/0x26b0 mm/memory.c:5219 do_user_addr_fault+0x69b/0xcb0 arch/x86/mm/fault.c:1428 handle_page_fault arch/x86/mm/fault.c:1519 [inline] exc_page_fault+0x7a/0x110 arch/x86/mm/fault.c:1575 asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:570 RIP: 0010:copy_user_short_string+0xd/0x40 arch/x86/lib/copy_user_64.S:233 Code: 74 0a 89 (...) RSP: 0018:ffffc9000570f330 EFLAGS: 000502 ---truncated--- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: bloquea el inodo en modo compartido antes de iniciar fiemap. Actualmente, fiemap no toma el bloqueo del inodo (bloqueo VFS), solo bloquea un rango de archivos en el árbol io del inodo. • https://git.kernel.org/stable/c/d8c594da79bc0244e610a70594e824a401802be1 https://git.kernel.org/stable/c/519b7e13b5ae8dd38da1e52275705343be6bb508 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52736 – ALSA: hda: Do not unset preset when cleaning up codec
https://notcve.org/view.php?id=CVE-2023-52736
In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: Do not unset preset when cleaning up codec Several functions that take part in codec's initialization and removal are re-used by ASoC codec drivers implementations. Drivers mimic the behavior of hda_codec_driver_probe/remove() found in sound/pci/hda/hda_bind.c with their component->probe/remove() instead. One of the reasons for that is the expectation of snd_hda_codec_device_new() to receive a valid pointer to an instance of struct snd_card. This expectation can be met only once sound card components probing commences. As ASoC sound card may be unbound without codec device being actually removed from the system, unsetting ->preset in snd_hda_codec_cleanup_for_unbind() interferes with module unload -> load scenario causing null-ptr-deref. Preset is assigned only once, during device/driver matching whereas ASoC codec driver's module reloading may occur several times throughout the lifetime of an audio stack. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: hda: no desarmar el valor predeterminado al limpiar el códec. • https://git.kernel.org/stable/c/7fc4e7191eae9d9325511e03deadfdb2224914f8 https://git.kernel.org/stable/c/e909f5f2aa55a8f9aa6919cce08015cb0e8d4668 https://git.kernel.org/stable/c/427ca2530da8dc61a42620d7113b05e187b6c2c0 https://git.kernel.org/stable/c/87978e6ad45a16835cc58234451111091be3c59a •
CVSS: 9.1EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52735 – bpf, sockmap: Don't let sock_map_{close,destroy,unhash} call itself
https://notcve.org/view.php?id=CVE-2023-52735
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Don't let sock_map_{close,destroy,unhash} call itself sock_map proto callbacks should never call themselves by design. Protect against bugs like [1] and break out of the recursive loop to avoid a stack overflow in favor of a resource leak. [1] https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/ En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: no permita que sock_map_{close,destroy,unhash} se llame a sí mismo. Las devoluciones de llamada del proto sock_map nunca deberían llamarse a sí mismas por diseño. Protéjase contra bugs como [1] y salga del bucle recursivo para evitar un desbordamiento de la pila que favorezca una fuga de recursos. [1] https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/ • https://git.kernel.org/stable/c/f312367f5246e04df564d341044286e9e37a97ba https://git.kernel.org/stable/c/7499859881488da97589f3c79cc66fa75748ad49 https://git.kernel.org/stable/c/5b4a79ba65a1ab479903fff2e604865d229b70a9 https://access.redhat.com/security/cve/CVE-2023-52735 https://bugzilla.redhat.com/show_bug.cgi?id=2282618 • CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') CWE-121: Stack-based Buffer Overflow •
CVSS: 7.8EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52733 – s390/decompressor: specify __decompress() buf len to avoid overflow
https://notcve.org/view.php?id=CVE-2023-52733
In the Linux kernel, the following vulnerability has been resolved: s390/decompressor: specify __decompress() buf len to avoid overflow Historically calls to __decompress() didn't specify "out_len" parameter on many architectures including s390, expecting that no writes beyond uncompressed kernel image are performed. This has changed since commit 2aa14b1ab2c4 ("zstd: import usptream v1.5.2") which includes zstd library commit 6a7ede3dfccb ("Reduce size of dctx by reutilizing dst buffer (#2751)"). Now zstd decompression code might store literal buffer in the unwritten portion of the destination buffer. Since "out_len" is not set, it is considered to be unlimited and hence free to use for optimization needs. On s390 this might corrupt initrd or ipl report which are often placed right after the decompressor buffer. • https://git.kernel.org/stable/c/16409f7d9ca5bb8220e1049ea9aae0d3c94d2dfb https://git.kernel.org/stable/c/55dbd6f4ea954751340f4f73d5dcd7c8f12208b2 https://git.kernel.org/stable/c/9ed522143f959630f8b7782ddc212900d8f609a9 https://git.kernel.org/stable/c/f1eb22d0ff064ad458b3b1a1eaa84ac3996206c2 https://git.kernel.org/stable/c/7ab41c2c08a32132ba8c14624910e2fe8ce4ba4b • CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2023-52732 – ceph: blocklist the kclient when receiving corrupted snap trace
https://notcve.org/view.php?id=CVE-2023-52732
In the Linux kernel, the following vulnerability has been resolved: ceph: blocklist the kclient when receiving corrupted snap trace When received corrupted snap trace we don't know what exactly has happened in MDS side. And we shouldn't continue IOs and metadatas access to MDS, which may corrupt or get incorrect contents. This patch will just block all the further IO/MDS requests immediately and then evict the kclient itself. The reason why we still need to evict the kclient just after blocking all the further IOs is that the MDS could revoke the caps faster. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ceph: lista de bloqueo del kclient cuando se recibe un seguimiento instantáneo corrupto. Cuando recibimos un seguimiento instantáneo corrupto, no sabemos qué ha sucedido exactamente en el lado MDS. Y no debemos continuar con el acceso de IO y metadatos a MDS, lo que puede dañar u obtener contenidos incorrectos. • https://git.kernel.org/stable/c/66ec619e4591f8350f99c5269a7ce160cccc7a7c https://git.kernel.org/stable/c/a68e564adcaa69b0930809fb64d9d5f7d9c32ba9 •