CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52774 – s390/dasd: protect device queue against concurrent access
https://notcve.org/view.php?id=CVE-2023-52774
In the Linux kernel, the following vulnerability has been resolved: s390/dasd: protect device queue against concurrent access In dasd_profile_start() the amount of requests on the device queue are counted. The access to the device queue is unprotected against concurrent access. With a lot of parallel I/O, especially with alias devices enabled, the device queue can change while dasd_profile_start() is accessing the queue. In the worst case this leads to a kernel panic due to incorrect pointer accesses. Fix this by taking the device lock before accessing the queue and counting the requests. Additionally the check for a valid profile data pointer can be done earlier to avoid unnecessary locking in a hot path. • https://git.kernel.org/stable/c/4fa52aa7a82f9226b3874a69816bda3af821f002 https://git.kernel.org/stable/c/ebdc569a07a3e8dbe66b4184922ad6f88ac0b96f https://git.kernel.org/stable/c/f75617cc8df4155374132f0b500b0b3ebb967458 https://git.kernel.org/stable/c/f1ac7789406e2ca9ac51c41ad2daa597f47bdd4d https://git.kernel.org/stable/c/c841de6247e94e07566d57163d3c0d8b29278f7a https://git.kernel.org/stable/c/6062c527d0403cef27c54b91ac8390c3a497b250 https://git.kernel.org/stable/c/dc96fde8fcb2b896fd6c64802a7f4ece2e69b0be https://git.kernel.org/stable/c/9372aab5d0ff621ea203c8c603e7e5f75 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52773 – drm/amd/display: fix a NULL pointer dereference in amdgpu_dm_i2c_xfer()
https://notcve.org/view.php?id=CVE-2023-52773
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix a NULL pointer dereference in amdgpu_dm_i2c_xfer() When ddc_service_construct() is called, it explicitly checks both the link type and whether there is something on the link which will dictate whether the pin is marked as hw_supported. If the pin isn't set or the link is not set (such as from unloading/reloading amdgpu in an IGT test) then fail the amdgpu_dm_i2c_xfer() call. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: corrige una desreferencia de puntero NULL en amdgpu_dm_i2c_xfer(). Cuando se llama a ddc_service_construct(), comprueba explícitamente tanto el tipo de enlace como si hay algo en el enlace que dictará si el pin está marcado como hw_supported. Si el pin no está configurado o el enlace no está configurado (por ejemplo, al descargar/recargar amdgpu en una prueba de IGT), falle la llamada amdgpu_dm_i2c_xfer(). • https://git.kernel.org/stable/c/22676bc500c27d987a0b42cbe162aebf783f1c38 https://git.kernel.org/stable/c/fb5c134ca589fe670430acc9e7ebf2691ca2476d https://git.kernel.org/stable/c/5b14cf37b9f01de0b28c6f8960019d4c7883ce42 https://git.kernel.org/stable/c/1d07b7e84276777dad3c8cfebdf8e739606f90c9 https://git.kernel.org/stable/c/b71f4ade1b8900d30c661d6c27f87c35214c398c • CWE-476: NULL Pointer Dereference •
CVSS: 7.8EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52772 – af_unix: fix use-after-free in unix_stream_read_actor()
https://notcve.org/view.php?id=CVE-2023-52772
In the Linux kernel, the following vulnerability has been resolved: af_unix: fix use-after-free in unix_stream_read_actor() syzbot reported the following crash [1] After releasing unix socket lock, u->oob_skb can be changed by another thread. We must temporarily increase skb refcount to make sure this other thread will not free the skb under us. [1] BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa7/0xc0 net/unix/af_unix.c:2866 Read of size 4 at addr ffff88801f3b9cc4 by task syz-executor107/5297 CPU: 1 PID: 5297 Comm: syz-executor107 Not tainted 6.6.0-syzkaller-15910-gb8e3a87a627b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0xc4/0x620 mm/kasan/report.c:475 kasan_report+0xda/0x110 mm/kasan/report.c:588 unix_stream_read_actor+0xa7/0xc0 net/unix/af_unix.c:2866 unix_stream_recv_urg net/unix/af_unix.c:2587 [inline] unix_stream_read_generic+0x19a5/0x2480 net/unix/af_unix.c:2666 unix_stream_recvmsg+0x189/0x1b0 net/unix/af_unix.c:2903 sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg+0xe2/0x170 net/socket.c:1066 ____sys_recvmsg+0x21f/0x5c0 net/socket.c:2803 ___sys_recvmsg+0x115/0x1a0 net/socket.c:2845 __sys_recvmsg+0x114/0x1e0 net/socket.c:2875 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7fc67492c559 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fc6748ab228 EFLAGS: 00000246 ORIG_RAX: 000000000000002f RAX: ffffffffffffffda RBX: 000000000000001c RCX: 00007fc67492c559 RDX: 0000000040010083 RSI: 0000000020000140 RDI: 0000000000000004 RBP: 00007fc6749b6348 R08: 00007fc6748ab6c0 R09: 00007fc6748ab6c0 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fc6749b6340 R13: 00007fc6749b634c R14: 00007ffe9fac52a0 R15: 00007ffe9fac5388 </TASK> Allocated by task 5295: kasan_save_stack+0x33/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x180/0x3c0 mm/slub.c:3523 __alloc_skb+0x287/0x330 net/core/skbuff.c:641 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xe4/0x710 net/core/skbuff.c:6331 sock_alloc_send_pskb+0x7e4/0x970 net/core/sock.c:2780 sock_alloc_send_skb include/net/sock.h:1884 [inline] queue_oob net/unix/af_unix.c:2147 [inline] unix_stream_sendmsg+0xb5f/0x10a0 net/unix/af_unix.c:2301 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584 ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638 __sys_sendmsg+0x117/0x1e0 net/socket.c:2667 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b Freed by task 5295: kasan_save_stack+0x33/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 kasan_save_free_info+0x2b/0x40 mm/kasan/generic.c:522 ____kasan_slab_free mm/kasan/common.c:236 [inline] ____kasan_slab_free+0x15b/0x1b0 mm/kasan/common.c:200 kasan_slab_free include/linux/kasan.h:164 [inline] slab_free_hook mm/slub.c:1800 [inline] slab_free_freelist_hook+0x114/0x1e0 mm/slub.c:1826 slab_free mm/slub.c:3809 [inline] kmem_cache_free+0xf8/0x340 mm/slub.c:3831 kfree_skbmem+0xef/0x1b0 net/core/skbuff.c:1015 __kfree_skb net/core/skbuff.c:1073 [inline] consume_skb net/core/skbuff.c:1288 [inline] consume_skb+0xdf/0x170 net/core/skbuff.c:1282 queue_oob net/unix/af_unix.c:2178 [inline] u ---truncated--- En el kernel de Linux, se resolvió la siguiente vulnerabilidad: af_unix: corrige use-after-free en unix_stream_read_actor() syzbot informó el siguiente bloqueo [1] Después de liberar el bloqueo del socket Unix, otro subproceso puede cambiar u->oob_skb. Debemos aumentar temporalmente el recuento de skb para asegurarnos de que este otro hilo no libere el skb que está debajo de nosotros. [1] ERROR: KASAN: slab-use-after-free en unix_stream_read_actor+0xa7/0xc0 net/unix/af_unix.c:2866 Lectura de tamaño 4 en la dirección ffff88801f3b9cc4 por tarea syz-executor107/5297 CPU: 1 PID: 5297 Comm : syz-executor107 No contaminado 6.6.0-syzkaller-15910-gb8e3a87a627b #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/10/2023 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [en línea] print_report+0xc4/0x620 mm/kasan/report.c:475 kasan_report+0xda/0x110 mm/kasan /report.c:588 unix_stream_read_actor+0xa7/0xc0 net/unix/af_unix.c:2866 unix_stream_recv_urg net/unix/af_unix.c:2587 [en línea] unix_stream_read_generic+0x19a5/0x2480 net/unix/af_unix.c:2666 +0x189 /0x1b0 net/unix/af_unix.c:2903 sock_recvmsg_nosec net/socket.c:1044 [en línea] sock_recvmsg+0xe2/0x170 net/socket.c:1066 ____sys_recvmsg+0x21f/0x5c0 net/socket.c:2803 ___sys_recv mensaje+0x115/ 0x1a0 net/socket.c:2845 __sys_recvmsg+0x114/0x1e0 net/socket.c:2875 do_syscall_x64 arch/x86/entry/common.c:51 [en línea] do_syscall_64+0x3f/0x110 arch/x86/entry/common.c: 82 Entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7fc67492c559 Código: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d 6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fc6748ab228 EFLAGS: 00000246 ORIG_RAX: 0000002f RAX: ffffffffffffffda RBX: 000000000000001c RCX: 00007fc67492c559 RDX : 0000000040010083 RSI: 0000000020000140 RDI: 0000000000000004 RBP: 00007fc6749b6348 R08: 00007fc6748ab6c0 R09: 00007fc6748ab6c0 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fc6749b6340 R13: 00007fc6749b634c R14: 00007ffe9fac52a0 R15: 00007ffe9fac5388 tarea 5295: kasan_save_stack+0x33/0x50 mm /kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [en línea] slab_post_alloc_hook mm/slab.h:763 [en línea] slab_alloc_node mm/slub.c:3478 [en línea] kmem_cache_alloc_node+0x180/0x3c0 mm/slub.c:3523 __alloc_skb+0x287/0x330 net/core/skbuff.c:641 alloc_skb include/ linux/skbuff.h:1286 [en línea] alloc_skb_with_frags+0xe4/0x710 net/core/skbuff.c:6331 sock_alloc_send_pskb+0x7e4/0x970 net/core/sock.c:2780 sock_alloc_send_skb include/net/sock.h:1884 [en línea ] queue_oob net/unix/af_unix.c:2147 [en línea] unix_stream_sendmsg+0xb5f/0x10a0 net/unix/af_unix.c:2301 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg+0xd5/0x180 net/socket.c: 745 ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584 ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638 __sys_sendmsg+0x117/0x1e0 net/socket.c:2667 do_syscall_x64 arch/x86/entry/ common.c:51 [ Inline] do_syscall_64+0x3f/0x110 Arch/x86/entry/Common.c: 82 entry_syscall_64_after_hwframe+0x63/0x6b liberado por tarea 5295: kasan_save_stack+0x33/0x50 mm/kasan/common.c:52 kasan_save_free_info+0x2b/0x40 mm/kasan/generic.c:522 ____kasan_slab_free mm/kasan/common.c:236 [en línea] ____kasan_slab_free+0x15b/0x1b0 mm/kasan/common.c:200 kasan_slab_free include/ linux/kasan.h:164 [en línea] slab_free_hook mm/slub.c:1800 [en línea] slab_free_freelist_hook+0x114/0x1e0 mm/slub.c:1826 slab_free mm/slub.c:3809 [en línea] kmem_cache_free+0xf8/0x340 mm /slub.c:3831 kfree_skbmem+0xef/0x1b0 net/core/skbuff.c:1015 __kfree_skb net/core/skbuff.c:1073 [en línea] consume_skb net/core/skbuff.c:1288 [en línea] consume_skb+0xdf/ 0x170 net/core/skbuff.c:1282 queue_oob net/unix/af_unix.c:2178 [en línea] u ---truncado--- • https://git.kernel.org/stable/c/876c14ad014d0e39c57cbfde53e13d17cdb6d645 https://git.kernel.org/stable/c/75bcfc188abf4fae9c1d5f5dc0a03540be602eef https://git.kernel.org/stable/c/d179189eec426fe4801e4b91efa1889faed12700 https://git.kernel.org/stable/c/eae0b295ce16d8c8b4114c3037993191b4bb92f0 https://git.kernel.org/stable/c/069a3ec329ff43e7869a3d94c62cd03203016bce https://git.kernel.org/stable/c/4b7b492615cf3017190f55444f7016812b66611d • CWE-416: Use After Free •
CVSS: 4.4EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52771 – cxl/port: Fix delete_endpoint() vs parent unregistration race
https://notcve.org/view.php?id=CVE-2023-52771
In the Linux kernel, the following vulnerability has been resolved: cxl/port: Fix delete_endpoint() vs parent unregistration race The CXL subsystem, at cxl_mem ->probe() time, establishes a lineage of ports (struct cxl_port objects) between an endpoint and the root of a CXL topology. Each port including the endpoint port is attached to the cxl_port driver. Given that setup, it follows that when either any port in that lineage goes through a cxl_port ->remove() event, or the memdev goes through a cxl_mem ->remove() event. The hierarchy below the removed port, or the entire hierarchy if the memdev is removed needs to come down. The delete_endpoint() callback is careful to check whether it is being called to tear down the hierarchy, or if it is only being called to teardown the memdev because an ancestor port is going through ->remove(). That care needs to take the device_lock() of the endpoint's parent. Which requires 2 bugs to be fixed: 1/ A reference on the parent is needed to prevent use-after-free scenarios like this signature: BUG: spinlock bad magic on CPU#0, kworker/u56:0/11 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc38 05/24/2023 Workqueue: cxl_port detach_memdev [cxl_core] RIP: 0010:spin_bug+0x65/0xa0 Call Trace: do_raw_spin_lock+0x69/0xa0 __mutex_lock+0x695/0xb80 delete_endpoint+0xad/0x150 [cxl_core] devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1d2/0x210 detach_memdev+0x15/0x20 [cxl_core] process_one_work+0x1e3/0x4c0 worker_thread+0x1dd/0x3d0 2/ In the case of RCH topologies, the parent device that needs to be locked is not always @port->dev as returned by cxl_mem_find_port(), use endpoint->dev.parent instead. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cxl/port: corrige delete_endpoint() frente a la ejecución de cancelación del registro principal. El subsistema CXL, en el momento cxl_mem ->probe(), establece un linaje de puertos (objetos struct cxl_port) entre un punto final y la raíz de una topología CXL. • https://git.kernel.org/stable/c/8dd2bc0f8e02d39bd80851ca787bcbdb7d495e69 https://git.kernel.org/stable/c/37179fcc916bce8c3cc7b36d67ef814cce55142b https://git.kernel.org/stable/c/6b2e428e673b3f55965674a426c40922e91388aa https://git.kernel.org/stable/c/8d2ad999ca3c64cb08cf6a58d227b9d9e746d708 https://access.redhat.com/security/cve/CVE-2023-52771 https://bugzilla.redhat.com/show_bug.cgi?id=2282720 • CWE-413: Improper Resource Locking •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52770 – f2fs: split initial and dynamic conditions for extent_cache
https://notcve.org/view.php?id=CVE-2023-52770
In the Linux kernel, the following vulnerability has been resolved: f2fs: split initial and dynamic conditions for extent_cache Let's allocate the extent_cache tree without dynamic conditions to avoid a missing condition causing a panic as below. # create a file w/ a compressed flag # disable the compression # panic while updating extent_cache F2FS-fs (dm-64): Swapfile: last extent is not aligned to section F2FS-fs (dm-64): Swapfile (3) is not align to section: 1) creat(), 2) ioctl(F2FS_IOC_SET_PIN_FILE), 3) fallocate(2097152 * N) Adding 124996k swap on ./swap-file. Priority:0 extents:2 across:17179494468k ================================================================== BUG: KASAN: null-ptr-deref in instrument_atomic_read_write out/common/include/linux/instrumented.h:101 [inline] BUG: KASAN: null-ptr-deref in atomic_try_cmpxchg_acquire out/common/include/asm-generic/atomic-instrumented.h:705 [inline] BUG: KASAN: null-ptr-deref in queued_write_lock out/common/include/asm-generic/qrwlock.h:92 [inline] BUG: KASAN: null-ptr-deref in __raw_write_lock out/common/include/linux/rwlock_api_smp.h:211 [inline] BUG: KASAN: null-ptr-deref in _raw_write_lock+0x5a/0x110 out/common/kernel/locking/spinlock.c:295 Write of size 4 at addr 0000000000000030 by task syz-executor154/3327 CPU: 0 PID: 3327 Comm: syz-executor154 Tainted: G O 5.10.185 #1 Hardware name: emulation qemu-x86/qemu-x86, BIOS 2023.01-21885-gb3cc1cd24d 01/01/2023 Call Trace: __dump_stack out/common/lib/dump_stack.c:77 [inline] dump_stack_lvl+0x17e/0x1c4 out/common/lib/dump_stack.c:118 __kasan_report+0x16c/0x260 out/common/mm/kasan/report.c:415 kasan_report+0x51/0x70 out/common/mm/kasan/report.c:428 kasan_check_range+0x2f3/0x340 out/common/mm/kasan/generic.c:186 __kasan_check_write+0x14/0x20 out/common/mm/kasan/shadow.c:37 instrument_atomic_read_write out/common/include/linux/instrumented.h:101 [inline] atomic_try_cmpxchg_acquire out/common/include/asm-generic/atomic-instrumented.h:705 [inline] queued_write_lock out/common/include/asm-generic/qrwlock.h:92 [inline] __raw_write_lock out/common/include/linux/rwlock_api_smp.h:211 [inline] _raw_write_lock+0x5a/0x110 out/common/kernel/locking/spinlock.c:295 __drop_extent_tree+0xdf/0x2f0 out/common/fs/f2fs/extent_cache.c:1155 f2fs_drop_extent_tree+0x17/0x30 out/common/fs/f2fs/extent_cache.c:1172 f2fs_insert_range out/common/fs/f2fs/file.c:1600 [inline] f2fs_fallocate+0x19fd/0x1f40 out/common/fs/f2fs/file.c:1764 vfs_fallocate+0x514/0x9b0 out/common/fs/open.c:310 ksys_fallocate out/common/fs/open.c:333 [inline] __do_sys_fallocate out/common/fs/open.c:341 [inline] __se_sys_fallocate out/common/fs/open.c:339 [inline] __x64_sys_fallocate+0xb8/0x100 out/common/fs/open.c:339 do_syscall_64+0x35/0x50 out/common/arch/x86/entry/common.c:46 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: f2fs: condiciones iniciales y dinámicas divididas para extend_cache. Asignemos el árbol extend_cache sin condiciones dinámicas para evitar que una condición faltante cause pánico como se muestra a continuación. # crear un archivo con una bandera comprimida # desactivar la compresión # entrar en pánico al actualizar extend_cache F2FS-fs (dm-64): Swapfile: la última extensión no está alineada con la sección F2FS-fs (dm-64): Swapfile (3) es no alinearse con la sección: 1) creat(), 2) ioctl(F2FS_IOC_SET_PIN_FILE), 3) fallocate(2097152 * N) Agregando 124996k swap en ./swap-file. • https://git.kernel.org/stable/c/72840cccc0a1a0a0dc1bb27b669a9111be6d0f6a https://git.kernel.org/stable/c/4377b1d3b19e1369d094a94596211a9815ddbb04 https://git.kernel.org/stable/c/9de787139b0258a5dd1f498780c26d76b61d2958 https://git.kernel.org/stable/c/d83309e7e006cee8afca83523559017c824fbf7a https://git.kernel.org/stable/c/f803982190f0265fd36cf84670aa6daefc2b0768 •