CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2022-48688 – i40e: Fix kernel crash during module removal
https://notcve.org/view.php?id=CVE-2022-48688
In the Linux kernel, the following vulnerability has been resolved: i40e: Fix kernel crash during module removal The driver incorrectly frees client instance and subsequent i40e module removal leads to kernel crash. Reproducer: 1. Do ethtool offline test followed immediately by another one host# ethtool -t eth0 offline; ethtool -t eth0 offline 2. Remove recursively irdma module that also removes i40e module host# modprobe -r irdma Result: [ 8675.035651] i40e 0000:3d:00.0 eno1: offline testing starting [ 8675.193774] i40e 0000:3d:00.0 eno1: testing finished [ 8675.201316] i40e 0000:3d:00.0 eno1: offline testing starting [ 8675.358921] i40e 0000:3d:00.0 eno1: testing finished [ 8675.496921] i40e 0000:3d:00.0: IRDMA hardware initialization FAILED init_state=2 status=-110 [ 8686.188955] i40e 0000:3d:00.1: i40e_ptp_stop: removed PHC on eno2 [ 8686.943890] i40e 0000:3d:00.1: Deleted LAN device PF1 bus=0x3d dev=0x00 func=0x01 [ 8686.952669] i40e 0000:3d:00.0: i40e_ptp_stop: removed PHC on eno1 [ 8687.761787] BUG: kernel NULL pointer dereference, address: 0000000000000030 [ 8687.768755] #PF: supervisor read access in kernel mode [ 8687.773895] #PF: error_code(0x0000) - not-present page [ 8687.779034] PGD 0 P4D 0 [ 8687.781575] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 8687.785935] CPU: 51 PID: 172891 Comm: rmmod Kdump: loaded Tainted: G W I 5.19.0+ #2 [ 8687.794800] Hardware name: Intel Corporation S2600WFD/S2600WFD, BIOS SE5C620.86B.0X.02.0001.051420190324 05/14/2019 [ 8687.805222] RIP: 0010:i40e_lan_del_device+0x13/0xb0 [i40e] [ 8687.810719] Code: d4 84 c0 0f 84 b8 25 01 00 e9 9c 25 01 00 41 bc f4 ff ff ff eb 91 90 0f 1f 44 00 00 41 54 55 53 48 8b 87 58 08 00 00 48 89 fb <48> 8b 68 30 48 89 ef e8 21 8a 0f d5 48 89 ef e8 a9 78 0f d5 48 8b [ 8687.829462] RSP: 0018:ffffa604072efce0 EFLAGS: 00010202 [ 8687.834689] RAX: 0000000000000000 RBX: ffff8f43833b2000 RCX: 0000000000000000 [ 8687.841821] RDX: 0000000000000000 RSI: ffff8f4b0545b298 RDI: ffff8f43833b2000 [ 8687.848955] RBP: ffff8f43833b2000 R08: 0000000000000001 R09: 0000000000000000 [ 8687.856086] R10: 0000000000000000 R11: 000ffffffffff000 R12: ffff8f43833b2ef0 [ 8687.863218] R13: ffff8f43833b2ef0 R14: ffff915103966000 R15: ffff8f43833b2008 [ 8687.870342] FS: 00007f79501c3740(0000) GS:ffff8f4adffc0000(0000) knlGS:0000000000000000 [ 8687.878427] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8687.884174] CR2: 0000000000000030 CR3: 000000014276e004 CR4: 00000000007706e0 [ 8687.891306] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 8687.898441] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 8687.905572] PKRU: 55555554 [ 8687.908286] Call Trace: [ 8687.910737] <TASK> [ 8687.912843] i40e_remove+0x2c0/0x330 [i40e] [ 8687.917040] pci_device_remove+0x33/0xa0 [ 8687.920962] device_release_driver_internal+0x1aa/0x230 [ 8687.926188] driver_detach+0x44/0x90 [ 8687.929770] bus_remove_driver+0x55/0xe0 [ 8687.933693] pci_unregister_driver+0x2a/0xb0 [ 8687.937967] i40e_exit_module+0xc/0xf48 [i40e] Two offline tests cause IRDMA driver failure (ETIMEDOUT) and this failure is indicated back to i40e_client_subtask() that calls i40e_client_del_instance() to free client instance referenced by pf->cinst and sets this pointer to NULL. During the module removal i40e_remove() calls i40e_lan_del_device() that dereferences pf->cinst that is NULL -> crash. Do not remove client instance when client open callbacks fails and just clear __I40E_CLIENT_INSTANCE_OPENED bit. The driver also needs to take care about this situation (when netdev is up and client is NOT opened) in i40e_notify_client_of_netdev_close() and calls client close callback only when __I40E_CLIENT_INSTANCE_OPENED is set. • https://git.kernel.org/stable/c/0ef2d5afb12d379f4dd5df696219a01b88bb778a https://git.kernel.org/stable/c/c49f320e2492738d478bc427dcd54ccfe0cba746 https://git.kernel.org/stable/c/5332a094514852d5e58c278cf4193adb937337fc https://git.kernel.org/stable/c/342d77769a6cceb3df7720a1e18baa4339eee3fc https://git.kernel.org/stable/c/2ed94383f3a2693dbf5bc47c514b42524bd8f9ae https://git.kernel.org/stable/c/38af35bec59a8431a1eb29da994a0a45cba275d9 https://git.kernel.org/stable/c/fb8396aeda5872369a8ed6d2301e2c86e303c520 • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2022-48687 – ipv6: sr: fix out-of-bounds read when setting HMAC data.
https://notcve.org/view.php?id=CVE-2022-48687
In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix out-of-bounds read when setting HMAC data. The SRv6 layer allows defining HMAC data that can later be used to sign IPv6 Segment Routing Headers. This configuration is realised via netlink through four attributes: SEG6_ATTR_HMACKEYID, SEG6_ATTR_SECRET, SEG6_ATTR_SECRETLEN and SEG6_ATTR_ALGID. Because the SECRETLEN attribute is decoupled from the actual length of the SECRET attribute, it is possible to provide invalid combinations (e.g., secret = "", secretlen = 64). This case is not checked in the code and with an appropriately crafted netlink message, an out-of-bounds read of up to 64 bytes (max secret length) can occur past the skb end pointer and into skb_shared_info: Breakpoint 1, seg6_genl_sethmac (skb=<optimized out>, info=<optimized out>) at net/ipv6/seg6.c:208 208 memcpy(hinfo->secret, secret, slen); (gdb) bt #0 seg6_genl_sethmac (skb=<optimized out>, info=<optimized out>) at net/ipv6/seg6.c:208 #1 0xffffffff81e012e9 in genl_family_rcv_msg_doit (skb=skb@entry=0xffff88800b1f9f00, nlh=nlh@entry=0xffff88800b1b7600, extack=extack@entry=0xffffc90000ba7af0, ops=ops@entry=0xffffc90000ba7a80, hdrlen=4, net=0xffffffff84237580 <init_net>, family=<optimized out>, family=<optimized out>) at net/netlink/genetlink.c:731 #2 0xffffffff81e01435 in genl_family_rcv_msg (extack=0xffffc90000ba7af0, nlh=0xffff88800b1b7600, skb=0xffff88800b1f9f00, family=0xffffffff82fef6c0 <seg6_genl_family>) at net/netlink/genetlink.c:775 #3 genl_rcv_msg (skb=0xffff88800b1f9f00, nlh=0xffff88800b1b7600, extack=0xffffc90000ba7af0) at net/netlink/genetlink.c:792 #4 0xffffffff81dfffc3 in netlink_rcv_skb (skb=skb@entry=0xffff88800b1f9f00, cb=cb@entry=0xffffffff81e01350 <genl_rcv_msg>) at net/netlink/af_netlink.c:2501 #5 0xffffffff81e00919 in genl_rcv (skb=0xffff88800b1f9f00) at net/netlink/genetlink.c:803 #6 0xffffffff81dff6ae in netlink_unicast_kernel (ssk=0xffff888010eec800, skb=0xffff88800b1f9f00, sk=0xffff888004aed000) at net/netlink/af_netlink.c:1319 #7 netlink_unicast (ssk=ssk@entry=0xffff888010eec800, skb=skb@entry=0xffff88800b1f9f00, portid=portid@entry=0, nonblock=<optimized out>) at net/netlink/af_netlink.c:1345 #8 0xffffffff81dff9a4 in netlink_sendmsg (sock=<optimized out>, msg=0xffffc90000ba7e48, len=<optimized out>) at net/netlink/af_netlink.c:1921 ... (gdb) p/x ((struct sk_buff *)0xffff88800b1f9f00)->head + ((struct sk_buff *)0xffff88800b1f9f00)->end $1 = 0xffff88800b1b76c0 (gdb) p/x secret $2 = 0xffff88800b1b76c0 (gdb) p slen $3 = 64 '@' The OOB data can then be read back from userspace by dumping HMAC state. This commit fixes this by ensuring SECRETLEN cannot exceed the actual length of SECRET. • https://git.kernel.org/stable/c/4f4853dc1c9c1994f6f756eabdcc25374ff271d9 https://git.kernel.org/stable/c/dc9dbd65c803af1607484fed5da50d41dc8dd864 https://git.kernel.org/stable/c/f684c16971ed5e77dfa25a9ad25b5297e1f58eab https://git.kernel.org/stable/c/3df71e11a4773d775c3633c44319f7acdb89011c https://git.kernel.org/stable/c/076f2479fc5a15c4a970ca3b5e57d42ba09a31fa https://git.kernel.org/stable/c/55195563ec29f80f984237b743de0e2b6ba4d093 https://git.kernel.org/stable/c/56ad3f475482bca55b0ae544031333018eb145b3 https://git.kernel.org/stable/c/84a53580c5d2138c7361c7c3eea5b3182 • CWE-125: Out-of-bounds Read •
CVSS: 7.8EPSS: 0%CPEs: 5EXPL: 0CVE-2022-48686 – nvme-tcp: fix UAF when detecting digest errors
https://notcve.org/view.php?id=CVE-2022-48686
In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix UAF when detecting digest errors We should also bail from the io_work loop when we set rd_enabled to true, so we don't attempt to read data from the socket when the TCP stream is already out-of-sync or corrupted. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme-tcp: corrige UAF al detectar errores de resumen. También debemos salir del bucle io_work cuando configuramos rd_enabled en verdadero, para no intentar leer datos del socket cuando el flujo TCP ya no está sincronizado o está dañado. A use-after-free vulnerability was found in the Linux kernel in drivers/nvme/host/tcp.c in nvme_tcp_io_work. This issue can occur when a local user continues to read data after the connection finishes. • https://git.kernel.org/stable/c/3f2304f8c6d6ed97849057bd16fee99e434ca796 https://git.kernel.org/stable/c/19816a0214684f70b49b25075ff8c402fdd611d3 https://git.kernel.org/stable/c/5914fa32ef1b7766fea933f9eed94ac5c00aa7ff https://git.kernel.org/stable/c/13c80a6c112467bab5e44d090767930555fc17a5 https://git.kernel.org/stable/c/c3eb461aa56e6fa94fb80442ba2586bd223a8886 https://git.kernel.org/stable/c/160f3549a907a50e51a8518678ba2dcf2541abea https://access.redhat.com/security/cve/CVE-2022-48686 https://bugzilla.redhat.com/show_bug.cgi?id=2278931 • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48675 – IB/core: Fix a nested dead lock as part of ODP flow
https://notcve.org/view.php?id=CVE-2022-48675
In the Linux kernel, the following vulnerability has been resolved: IB/core: Fix a nested dead lock as part of ODP flow Fix a nested dead lock as part of ODP flow by using mmput_async(). From the below call trace [1] can see that calling mmput() once we have the umem_odp->umem_mutex locked as required by ib_umem_odp_map_dma_and_lock() might trigger in the same task the exit_mmap()->__mmu_notifier_release()->mlx5_ib_invalidate_range() which may dead lock when trying to lock the same mutex. Moving to use mmput_async() will solve the problem as the above exit_mmap() flow will be called in other task and will be executed once the lock will be available. [1] [64843.077665] task:kworker/u133:2 state:D stack: 0 pid:80906 ppid: 2 flags:0x00004000 [64843.077672] Workqueue: mlx5_ib_page_fault mlx5_ib_eqe_pf_action [mlx5_ib] [64843.077719] Call Trace: [64843.077722] <TASK> [64843.077724] __schedule+0x23d/0x590 [64843.077729] schedule+0x4e/0xb0 [64843.077735] schedule_preempt_disabled+0xe/0x10 [64843.077740] __mutex_lock.constprop.0+0x263/0x490 [64843.077747] __mutex_lock_slowpath+0x13/0x20 [64843.077752] mutex_lock+0x34/0x40 [64843.077758] mlx5_ib_invalidate_range+0x48/0x270 [mlx5_ib] [64843.077808] __mmu_notifier_release+0x1a4/0x200 [64843.077816] exit_mmap+0x1bc/0x200 [64843.077822] ? walk_page_range+0x9c/0x120 [64843.077828] ? __cond_resched+0x1a/0x50 [64843.077833] ? mutex_lock+0x13/0x40 [64843.077839] ? uprobe_clear_state+0xac/0x120 [64843.077860] mmput+0x5f/0x140 [64843.077867] ib_umem_odp_map_dma_and_lock+0x21b/0x580 [ib_core] [64843.077931] pagefault_real_mr+0x9a/0x140 [mlx5_ib] [64843.077962] pagefault_mr+0xb4/0x550 [mlx5_ib] [64843.077992] pagefault_single_data_segment.constprop.0+0x2ac/0x560 [mlx5_ib] [64843.078022] mlx5_ib_eqe_pf_action+0x528/0x780 [mlx5_ib] [64843.078051] process_one_work+0x22b/0x3d0 [64843.078059] worker_thread+0x53/0x410 [64843.078065] ? • https://git.kernel.org/stable/c/36f30e486dce22345c2dd3a3ba439c12cd67f6ba https://git.kernel.org/stable/c/e8de6cb5755eae7b793d8c00c8696c8667d44a7f https://git.kernel.org/stable/c/819110054b14d7272b4188db997a3d80f75ab785 https://git.kernel.org/stable/c/83c43fd872e32c8071d5582eb7c40f573a8342f3 https://git.kernel.org/stable/c/85eaeb5058f0f04dffb124c97c86b4f18db0b833 • CWE-667: Improper Locking •
CVSS: 7.8EPSS: 0%CPEs: 5EXPL: 0CVE-2022-48674 – erofs: fix pcluster use-after-free on UP platforms
https://notcve.org/view.php?id=CVE-2022-48674
In the Linux kernel, the following vulnerability has been resolved: erofs: fix pcluster use-after-free on UP platforms During stress testing with CONFIG_SMP disabled, KASAN reports as below: ================================================================== BUG: KASAN: use-after-free in __mutex_lock+0xe5/0xc30 Read of size 8 at addr ffff8881094223f8 by task stress/7789 CPU: 0 PID: 7789 Comm: stress Not tainted 6.0.0-rc1-00002-g0d53d2e882f9 #3 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 Call Trace: <TASK> .. __mutex_lock+0xe5/0xc30 .. z_erofs_do_read_page+0x8ce/0x1560 .. z_erofs_readahead+0x31c/0x580 .. Freed by task 7787 kasan_save_stack+0x1e/0x40 kasan_set_track+0x20/0x30 kasan_set_free_info+0x20/0x40 __kasan_slab_free+0x10c/0x190 kmem_cache_free+0xed/0x380 rcu_core+0x3d5/0xc90 __do_softirq+0x12d/0x389 Last potentially related work creation: kasan_save_stack+0x1e/0x40 __kasan_record_aux_stack+0x97/0xb0 call_rcu+0x3d/0x3f0 erofs_shrink_workstation+0x11f/0x210 erofs_shrink_scan+0xdc/0x170 shrink_slab.constprop.0+0x296/0x530 drop_slab+0x1c/0x70 drop_caches_sysctl_handler+0x70/0x80 proc_sys_call_handler+0x20a/0x2f0 vfs_write+0x555/0x6c0 ksys_write+0xbe/0x160 do_syscall_64+0x3b/0x90 The root cause is that erofs_workgroup_unfreeze() doesn't reset to orig_val thus it causes a race that the pcluster reuses unexpectedly before freeing. Since UP platforms are quite rare now, such path becomes unnecessary. Let's drop such specific-designed path directly instead. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: erofs: corrige el use-after-free de pcluster en plataformas UP Durante las pruebas de estrés con CONFIG_SMP deshabilitado, KASAN informa lo siguiente: ============== ==================================================== == ERROR: KASAN: use-after-free en __mutex_lock+0xe5/0xc30 Lectura de tamaño 8 en la dirección ffff8881094223f8 por tarea estrés/7789 CPU: 0 PID: 7789 Comm: estrés No contaminado 6.0.0-rc1-00002-g0d53d2e882f9 # 3 Nombre del hardware: Red Hat KVM, BIOS 0.5.1 01/01/2011 Seguimiento de llamadas: .. __mutex_lock+0xe5/0xc30 .. z_erofs_do_read_page+0x8ce/0x1560 .. z_erofs_readahead+0x31c/0x580 .. Liberado por la tarea 7787 kasan_save_stack+0x1e/0x40 kasan_set_track+0x20/0x30 kasan_set_free_info+0x20/0x40 __kasan_slab_free+0x10c/0x190 kmem_cache_free+0xed/0x380 rcu_core+0x3d5/0xc90 __do_softirq+0x12d/0x 389 Última creación de trabajo potencialmente relacionado: kasan_save_stack+0x1e/0x40 __kasan_record_aux_stack+0x97/ 0xb0 call_rcu+0x3d/0x3f0 erofs_shrink_workstation+0x11f/0x210 erofs_shrink_scan+0xdc/0x170 retract_slab.constprop.0+0x296/0x530 drop_slab+0x1c/0x70 drop_caches_sysctl_handler+0x70/0x80 proc_sys_call_handler+0x20a/0x2f0 vfs_write+0x555/0x6c0 ksys_write+0xbe/0x160 do_syscall_64+0x3b/0x90 La causa principal es que erofs_workgroup_unfreeze() no se restablece a orig_val, por lo que provoca una carrera que el pcluster reutiliza inesperadamente antes de liberarse. Dado que las plataformas UP son bastante raras ahora, ese camino se vuelve innecesario. • https://git.kernel.org/stable/c/73f5c66df3e26ab750cefcb9a3e08c71c9f79cad https://git.kernel.org/stable/c/08ec9e6892cc792d7f8fe4d13bd8a0e91fb23488 https://git.kernel.org/stable/c/78c46113413bea1cc345757112aa2642e0f66de5 https://git.kernel.org/stable/c/8ddd001cef5e82d19192e6861068463ecca5f556 https://git.kernel.org/stable/c/94c34faaafe7b55adc2d8d881db195b646959b9e https://git.kernel.org/stable/c/2f44013e39984c127c6efedf70e6b5f4e9dcf315 • CWE-416: Use After Free •