CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52742 – net: USB: Fix wrong-direction WARNING in plusb.c
https://notcve.org/view.php?id=CVE-2023-52742
In the Linux kernel, the following vulnerability has been resolved: net: USB: Fix wrong-direction WARNING in plusb.c The syzbot fuzzer detected a bug in the plusb network driver: A zero-length control-OUT transfer was treated as a read instead of a write. In modern kernels this error provokes a WARNING: usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0 WARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411 usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 Modules linked in: CPU: 1 PID: 4645 Comm: dhcpcd Not tainted 6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 ... Call Trace: <TASK> usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153 __usbnet_read_cmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010 usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068 pl_vendor_req drivers/net/usb/plusb.c:60 [inline] pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline] pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85 usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889 __dev_open+0x297/0x4d0 net/core/dev.c:1417 __dev_change_flags+0x587/0x750 net/core/dev.c:8530 dev_change_flags+0x97/0x170 net/core/dev.c:8602 devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147 inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979 sock_do_ioctl+0xcc/0x230 net/socket.c:1169 sock_ioctl+0x1f8/0x680 net/socket.c:1286 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd The fix is to call usbnet_write_cmd() instead of usbnet_read_cmd() and remove the USB_DIR_IN flag. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: USB: corrija la dirección incorrecta ADVERTENCIA en plusb.c. El syzbot fuzzer detectó un error en el controlador de red plusb: una transferencia de control de salida de longitud cero se trató como una lectura en lugar de escribir. En los kernels modernos, este error provoca una ADVERTENCIA: usb 1-1: directorio de control BOGUS, la tubería 80000280 no coincide con bRequestType c0 ADVERTENCIA: CPU: 0 PID: 4645 en drivers/usb/core/urb.c:411 usb_submit_urb+0x14a7/ 0x1880 drivers/usb/core/urb.c:411 Módulos vinculados en: CPU: 1 PID: 4645 Comm: dhcpcd Not tainted 6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Motor, BIOS Google 12/01/2023 RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411... • https://git.kernel.org/stable/c/090ffa9d0e904e1ed0f86c84dcf20684a8ac1a5a https://git.kernel.org/stable/c/f0ad46ef772438c0596df370450d8bdc8a12dbfb https://git.kernel.org/stable/c/6f69307f625904feed189008381fd83bd1a35b63 https://git.kernel.org/stable/c/43379fcacea2dcee35d02efc9c8fe97807a503c9 https://git.kernel.org/stable/c/1be271c52bf3554edcb8d124d1f8c7f777ee5727 https://git.kernel.org/stable/c/25141fb4119112f4ebf8f00cf52014abbc8020b1 https://git.kernel.org/stable/c/0d2cf3fae701646061e295815bb7588d2f3671cc https://git.kernel.org/stable/c/811d581194f7412eda97acc03d17fc778 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52741 – cifs: Fix use-after-free in rdata->read_into_pages()
https://notcve.org/view.php?id=CVE-2023-52741
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix use-after-free in rdata->read_into_pages() When the network status is unstable, use-after-free may occur when read data from the server. BUG: KASAN: use-after-free in readpages_fill_pages+0x14c/0x7e0 Call Trace: <TASK> dump_stack_lvl+0x38/0x4c print_report+0x16f/0x4a6 kasan_report+0xb7/0x130 readpages_fill_pages+0x14c/0x7e0 cifs_readv_receive+0x46d/0xa40 cifs_demultiplex_thread+0x121c/0x1490 kthread+0x16b/0x1a0 ret_from_fork+0x2c/0x50 </TASK> Allocated by task 2535: kasan_save_stack+0x22/0x50 kasan_set_track+0x25/0x30 __kasan_kmalloc+0x82/0x90 cifs_readdata_direct_alloc+0x2c/0x110 cifs_readdata_alloc+0x2d/0x60 cifs_readahead+0x393/0xfe0 read_pages+0x12f/0x470 page_cache_ra_unbounded+0x1b1/0x240 filemap_get_pages+0x1c8/0x9a0 filemap_read+0x1c0/0x540 cifs_strict_readv+0x21b/0x240 vfs_read+0x395/0x4b0 ksys_read+0xb8/0x150 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc Freed by task 79: kasan_save_stack+0x22/0x50 kasan_set_track+0x25/0x30 kasan_save_free_info+0x2e/0x50 __kasan_slab_free+0x10e/0x1a0 __kmem_cache_free+0x7a/0x1a0 cifs_readdata_release+0x49/0x60 process_one_work+0x46c/0x760 worker_thread+0x2a4/0x6f0 kthread+0x16b/0x1a0 ret_from_fork+0x2c/0x50 Last potentially related work creation: kasan_save_stack+0x22/0x50 __kasan_record_aux_stack+0x95/0xb0 insert_work+0x2b/0x130 __queue_work+0x1fe/0x660 queue_work_on+0x4b/0x60 smb2_readv_callback+0x396/0x800 cifs_abort_connection+0x474/0x6a0 cifs_reconnect+0x5cb/0xa50 cifs_readv_from_socket.cold+0x22/0x6c cifs_read_page_from_socket+0xc1/0x100 readpages_fill_pages.cold+0x2f/0x46 cifs_readv_receive+0x46d/0xa40 cifs_demultiplex_thread+0x121c/0x1490 kthread+0x16b/0x1a0 ret_from_fork+0x2c/0x50 The following function calls will cause UAF of the rdata pointer. readpages_fill_pages cifs_read_page_from_socket cifs_readv_from_socket cifs_reconnect __cifs_reconnect cifs_abort_connection mid->callback() --> smb2_readv_callback queue_work(&rdata->work) # if the worker completes first, # the rdata is freed cifs_readv_complete kref_put cifs_readdata_release kfree(rdata) return rdata->... # UAF in readpages_fill_pages() Similarly, this problem also occurs in the uncache_fill_pages(). Fix this by adjusts the order of condition judgment in the return statement. • https://git.kernel.org/stable/c/2b693fe3f760c87fd9768e759f6297f743a1b3b0 https://git.kernel.org/stable/c/d1fba1e096ffc7ec11df863a97c50203c47315b9 https://git.kernel.org/stable/c/3684a2f6affa1ca52a5d4a12f04d0652efdee65e https://git.kernel.org/stable/c/aa5465aeca3c66fecdf7efcf554aed79b4c4b211 •
CVSS: 4.1EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52740 – powerpc/64s/interrupt: Fix interrupt exit race with security mitigation switch
https://notcve.org/view.php?id=CVE-2023-52740
In the Linux kernel, the following vulnerability has been resolved: powerpc/64s/interrupt: Fix interrupt exit race with security mitigation switch The RFI and STF security mitigation options can flip the interrupt_exit_not_reentrant static branch condition concurrently with the interrupt exit code which tests that branch. Interrupt exit tests this condition to set MSR[EE|RI] for exit, then again in the case a soft-masked interrupt is found pending, to recover the MSR so the interrupt can be replayed before attempting to exit again. If the condition changes between these two tests, the MSR and irq soft-mask state will become corrupted, leading to warnings and possible crashes. For example, if the branch is initially true then false, MSR[EE] will be 0 but PACA_IRQ_HARD_DIS clear and EE may not get enabled, leading to warnings in irq_64.c. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/64s/interrupt: corrige la ejecución de salida de interrupción con un interruptor de mitigación de seguridad. Las opciones de mitigación de seguridad RFI y STF pueden invertir la condición de rama estática interrupt_exit_not_reentrant al mismo tiempo que el código de salida de interrupción que prueba esa rama. . • https://git.kernel.org/stable/c/13799748b957bc5659f97c036224b0f4b42172e2 https://git.kernel.org/stable/c/86f7e423933608d536015a0f2eb9e0338c1227e0 https://git.kernel.org/stable/c/6f097c24815e67909a1fcc2c605586d02babd673 https://git.kernel.org/stable/c/2ea31e2e62bbc4d11c411eeb36f1b02841dbcab1 https://access.redhat.com/security/cve/CVE-2023-52740 https://bugzilla.redhat.com/show_bug.cgi?id=2282741 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52739 – Fix page corruption caused by racy check in __free_pages
https://notcve.org/view.php?id=CVE-2023-52739
In the Linux kernel, the following vulnerability has been resolved: Fix page corruption caused by racy check in __free_pages When we upgraded our kernel, we started seeing some page corruption like the following consistently: BUG: Bad page state in process ganesha.nfsd pfn:1304ca page:0000000022261c55 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0 pfn:0x1304ca flags: 0x17ffffc0000000() raw: 0017ffffc0000000 ffff8a513ffd4c98 ffffeee24b35ec08 0000000000000000 raw: 0000000000000000 0000000000000001 00000000ffffff7f 0000000000000000 page dumped because: nonzero mapcount CPU: 0 PID: 15567 Comm: ganesha.nfsd Kdump: loaded Tainted: P B O 5.10.158-1.nutanix.20221209.el7.x86_64 #1 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/05/2016 Call Trace: dump_stack+0x74/0x96 bad_page.cold+0x63/0x94 check_new_page_bad+0x6d/0x80 rmqueue+0x46e/0x970 get_page_from_freelist+0xcb/0x3f0 ? _cond_resched+0x19/0x40 __alloc_pages_nodemask+0x164/0x300 alloc_pages_current+0x87/0xf0 skb_page_frag_refill+0x84/0x110 ... Sometimes, it would also show up as corruption in the free list pointer and cause crashes. After bisecting the issue, we found the issue started from commit e320d3012d25 ("mm/page_alloc.c: fix freeing non-compound pages"): if (put_page_testzero(page)) free_the_page(page, order); else if (!PageHead(page)) while (order-- > 0) free_the_page(page + (1 << order), order); So the problem is the check PageHead is racy because at this point we already dropped our reference to the page. So even if we came in with compound page, the page can already be freed and PageHead can return false and we will end up freeing all the tail pages causing double free. • https://git.kernel.org/stable/c/e320d3012d25b1fb5f3df4edb7bd44a1c362ec10 https://git.kernel.org/stable/c/830b103831a924a23af48562c4d274696e75ab4f https://git.kernel.org/stable/c/0a626e27f984dfbe96bd8e4fd08f20a2ede3ea23 https://git.kernel.org/stable/c/3af734f3eac6f70ef8e272a80da40544b9d0f2b5 https://git.kernel.org/stable/c/3b4c045a98f53a8890a94bb5846a390c8e39e673 https://git.kernel.org/stable/c/462a8e08e0e6287e5ce13187257edbf24213ed03 •
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 •