CVSS: 5.3EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52738 – drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini
https://notcve.org/view.php?id=CVE-2023-52738
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini Currently amdgpu calls drm_sched_fini() from the fence driver sw fini routine - such function is expected to be called only after the respective init function - drm_sched_init() - was executed successfully. Happens that we faced a driver probe failure in the Steam Deck recently, and the function drm_sched_fini() was called even without its counter-part had been previously called, causing the following oops: amdgpu: probe of 0000:04:00.0 failed with error -110 BUG: kernel NULL pointer dereference, address: 0000000000000090 PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 609 Comm: systemd-udevd Not tainted 6.2.0-rc3-gpiccoli #338 Hardware name: Valve Jupiter/Jupiter, BIOS F7A0113 11/04/2022 RIP: 0010:drm_sched_fini+0x84/0xa0 [gpu_sched] [...] Call Trace: <TASK> amdgpu_fence_driver_sw_fini+0xc8/0xd0 [amdgpu] amdgpu_device_fini_sw+0x2b/0x3b0 [amdgpu] amdgpu_driver_release_kms+0x16/0x30 [amdgpu] devm_drm_dev_init_release+0x49/0x70 [...] To prevent that, check if the drm_sched was properly initialized for a given ring before calling its fini counter-part. Notice ideally we'd use sched.ready for that; such field is set as the latest thing on drm_sched_init(). But amdgpu seems to "override" the meaning of such field - in the above oops for example, it was a GFX ring causing the crash, and the sched.ready field was set to true in the ring init routine, regardless of the state of the DRM scheduler. Hence, we ended-up using sched.ops as per Christian's suggestion [0], and also removed the no_scheduler check [1]. [0] https://lore.kernel.org/amd-gfx/984ee981-2906-0eaf-ccec-9f80975cb136@amd.com/ [1] https://lore.kernel.org/amd-gfx/cd0e2994-f85f-d837-609f-7056d5fb7231@amd.com/ En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu/fence: se solucionó el error debido a que drm_sched init/fini no coincide. Actualmente, amdgpu llama a drm_sched_fini() desde la rutina SW fini del controlador de valla; se espera que se llame a dicha función. sólo después de que la función de inicio respectiva, drm_sched_init(), se haya ejecutado correctamente. Sucede que recientemente nos enfrentamos a una falla en la sonda del controlador en Steam Deck, y se llamó a la función drm_sched_fini() incluso sin que su contraparte se hubiera llamado previamente, lo que provocó el siguiente error: amdgpu: la sonda de 0000:04:00.0 falló con error -110 ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000090 PGD 0 P4D 0 Ups: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 609 Comm: systemd-udevd No contaminado 6.2.0-rc3-gpiccoli #338 Nombre del hardware : Valve Jupiter/Jupiter, BIOS F7A0113 04/11/2022 RIP: 0010:drm_sched_fini+0x84/0xa0 [gpu_sched] [...] • https://git.kernel.org/stable/c/067f44c8b4590c3f24d21a037578a478590f2175 https://git.kernel.org/stable/c/8ba968ae672b3075794c8086aa164595b0175abe https://git.kernel.org/stable/c/2e557c8ca2c585bdef591b8503ba83b85f5d0afd https://git.kernel.org/stable/c/2bcbbef9cace772f5b7128b11401c515982de34b https://git.kernel.org/stable/c/5ad7bbf3dba5c4a684338df1f285080f2588b535 •
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') •