CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52775 – net/smc: avoid data corruption caused by decline
https://notcve.org/view.php?id=CVE-2023-52775
In the Linux kernel, the following vulnerability has been resolved: net/smc: avoid data corruption caused by decline We found a data corruption issue during testing of SMC-R on Redis applications. The benchmark has a low probability of reporting a strange error as shown below. "Error: Protocol error, got "\xe2" as reply type byte" Finally, we found that the retrieved error data was as follows: 0xE2 0xD4 0xC3 0xD9 0x04 0x00 0x2C 0x20 0xA6 0x56 0x00 0x16 0x3E 0x0C 0xCB 0x04 0x02 0x01 0x00 0x00 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xE2 It is quite obvious that this is a SMC DECLINE message, which means that the applications received SMC protocol message. We found that this was caused by the following situations: client server ¦ clc proposal -------------> ¦ clc accept <------------- ¦ clc confirm -------------> wait llc confirm send llc confirm ¦failed llc confirm ¦ x------ (after 2s)timeout wait llc confirm rsp wait decline (after 1s) timeout (after 2s) timeout ¦ decline --------------> ¦ decline <-------------- As a result, a decline message was sent in the implementation, and this message was read from TCP by the already-fallback connection. This patch double the client timeout as 2x of the server value, With this simple change, the Decline messages should never cross or collide (during Confirm link timeout). This issue requires an immediate solution, since the protocol updates involve a more long-term solution. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/smc: evita la corrupción de datos causada por el rechazo. Encontramos un problema de corrupción de datos durante las pruebas de SMC-R en aplicaciones Redis. El punto de referencia tiene una baja probabilidad de informar un error extraño, como se muestra a continuación. "Error: Error de protocolo, obtuve "\xe2" como byte de tipo de respuesta" Finalmente, encontramos que los datos de error recuperados eran los siguientes: 0xE2 0xD4 0xC3 0xD9 0x04 0x00 0x2C 0x20 0xA6 0x56 0x00 0x16 0x3E 0x0C 0xCB 0x04 0x02 1 0x00 0x00 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xE2 Es bastante obvio que este es un mensaje SMC DECLINE, lo que significa que las aplicaciones recibieron un mensaje de protocolo SMC. • https://git.kernel.org/stable/c/0fb0b02bd6fd26cba38002be4a6bbcae2228fd44 https://git.kernel.org/stable/c/5ada292b5c504720a0acef8cae9acc62a694d19c https://git.kernel.org/stable/c/90072af9efe8c7bd7d086709014ddd44cebd5e7c https://git.kernel.org/stable/c/94a0ae698b4d5d5bb598e23228002a1491c50add https://git.kernel.org/stable/c/7234d2b5dffa5af77fd4e0deaebab509e130c6b1 https://git.kernel.org/stable/c/e6d71b437abc2f249e3b6a1ae1a7228e09c6e563 https://access.redhat.com/security/cve/CVE-2023-52775 https://bugzilla.redhat.com/show_bug.cgi?id=2282690 • CWE-20: Improper Input Validation •
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 •