CVSS: 7.1EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48855 – sctp: fix kernel-infoleak for SCTP sockets
https://notcve.org/view.php?id=CVE-2022-48855
In the Linux kernel, the following vulnerability has been resolved: sctp: fix kernel-infoleak for SCTP sockets syzbot reported a kernel infoleak [1] of 4 bytes. After analysis, it turned out r->idiag_expires is not initialized if inet_sctp_diag_fill() calls inet_diag_msg_common_fill() Make sure to clear idiag_timer/idiag_retrans/idiag_expires and let inet_diag_msg_sctpasoc_fill() fill them again if needed. [1] BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline] BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:154 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668 instrument_copy_to_user include/linux/instrumented.h:121 [inline] copyout lib/iov_iter.c:154 [inline] _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668 copy_to_iter include/linux/uio.h:162 [inline] simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519 __skb_datagram_iter+0x2d5/0x11b0 net/core/datagram.c:425 skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533 skb_copy_datagram_msg include/linux/skbuff.h:3696 [inline] netlink_recvmsg+0x669/0x1c80 net/netlink/af_netlink.c:1977 sock_recvmsg_nosec net/socket.c:948 [inline] sock_recvmsg net/socket.c:966 [inline] __sys_recvfrom+0x795/0xa10 net/socket.c:2097 __do_sys_recvfrom net/socket.c:2115 [inline] __se_sys_recvfrom net/socket.c:2111 [inline] __x64_sys_recvfrom+0x19d/0x210 net/socket.c:2111 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae Uninit was created at: slab_post_alloc_hook mm/slab.h:737 [inline] slab_alloc_node mm/slub.c:3247 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4975 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1158 [inline] netlink_dump+0x3e5/0x16c0 net/netlink/af_netlink.c:2248 __netlink_dump_start+0xcf8/0xe90 net/netlink/af_netlink.c:2373 netlink_dump_start include/linux/netlink.h:254 [inline] inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1341 sock_diag_rcv_msg+0x24a/0x620 netlink_rcv_skb+0x40c/0x7e0 net/netlink/af_netlink.c:2494 sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:277 netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline] netlink_unicast+0x1093/0x1360 net/netlink/af_netlink.c:1343 netlink_sendmsg+0x14d9/0x1720 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg net/socket.c:725 [inline] sock_write_iter+0x594/0x690 net/socket.c:1061 do_iter_readv_writev+0xa7f/0xc70 do_iter_write+0x52c/0x1500 fs/read_write.c:851 vfs_writev fs/read_write.c:924 [inline] do_writev+0x645/0xe00 fs/read_write.c:967 __do_sys_writev fs/read_write.c:1040 [inline] __se_sys_writev fs/read_write.c:1037 [inline] __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae Bytes 68-71 of 2508 are uninitialized Memory access of size 2508 starts at ffff888114f9b000 Data copied to user address 00007f7fe09ff2e0 CPU: 1 PID: 3478 Comm: syz-executor306 Not tainted 5.17.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: corrige la fuga de información del kernel para sockets SCTP syzbot informó una fuga de información del kernel [1] de 4 bytes. Después del análisis, resultó que r->idiag_expires no se inicializa si inet_sctp_diag_fill() llama a inet_diag_msg_common_fill(). Asegúrese de borrar idiag_timer/idiag_retrans/idiag_expires y deje que inet_diag_msg_sctpasoc_fill() los complete nuevamente si es necesario. [1] ERROR: KMSAN: kernel-infoleak en instrument_copy_to_user include/linux/instrumented.h:121 [en línea] ERROR: KMSAN: kernel-infoleak en copia lib/iov_iter.c:154 [en línea] ERROR: KMSAN: kernel-infoleak en _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668 instrument_copy_to_user include/linux/instrumented.h:121 [en línea] copia lib/iov_iter.c:154 [en línea] _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668 copy_to_iter include/linux/uio.h:162 [en línea] simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519 __skb_datagram_iter+0x2d5/0x11b0 net/core/datagram.c:425 skb_copy_datagram_iter+0xdc/0x270 net/core/datagram .c:533 skb_copy_datagram_msg include/linux/skbuff.h:3696 [en línea] netlink_recvmsg+0x669/0x1c80 net/netlink/af_netlink.c:1977 sock_recvmsg_nosec net/socket.c:948 [en línea] sock_recvmsg net/socket.c:966 [en línea] __sys_recvfrom+0x795/0xa10 net/socket.c:2097 __do_sys_recvfrom net/socket.c:2115 [en línea] __se_sys_recvfrom net/socket.c:2111 [en línea] __x64_sys_recvfrom+0x19d/0x210 net/socket.c: 2111 hacer_syscall_x64 arch/x86/entry/common.c:51 [en línea] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 Entry_SYSCALL_64_after_hwframe+0x44/0xae Uninit se creó en: slab_post_alloc_hook mm/slab.h:737 [en línea ] slab_alloc_node mm/slub.c:3247 [en línea] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4975 kmalloc_reserve net/core/skbuff.c:354 [en línea] __alloc_skb+0x545/0xf90 net/core/skbuff.c: 426 alloc_skb include/linux/skbuff.h:1158 [en línea] netlink_dump+0x3e5/0x16c0 net/netlink/af_netlink.c:2248 __netlink_dump_start+0xcf8/0xe90 net/netlink/af_netlink.c:2373 netlink_dump_start include/linux/netlink.h :254 [en línea] inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1341 sock_diag_rcv_msg+0x24a/0x620 netlink_rcv_skb+0x40c/0x7e0 net/netlink/af_netlink.c:2494 sock_diag_rcv+0x63/ 0x80 net/core/sock_diag.c : 277 netlink_unicast_kernel net/netlink/af_netlink.c: 1317 [en línea] netlink_unicast+0x1093/0x1360 netlink/af_netlink.c: 1343 netlink_sendmsg+0x14d9/0x1720 net/netlink/socks OCKE.C: 705 [en línea] sock_sendmsg net/socket.c:725 [en línea] sock_write_iter+0x594/0x690 net/socket.c:1061 do_iter_readv_writev+0xa7f/0xc70 do_iter_write+0x52c/0x1500 fs/read_write.c:851 vfs_writev fs/read_ escribir.c :924 [en línea] do_writev+0x645/0xe00 fs/read_write.c:967 __do_sys_writev fs/read_write.c:1040 [en línea] __se_sys_writev fs/read_write.c:1037 [en línea] __x64_sys_writev+0xe5/0x120 fs/read_write.c: 1037 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 Entry_SYSCALL_64_after_hwframe+0x44/0xae Los bytes 68-71 de 2508 no están inicializados Acceso a memoria de tamaño 2508 comienza en ffff888114f9b000 Datos copiados a la dirección de usuario 00007f7fe09ff2e0 CPU: 1 PID: 3478 Comm: syz-executor306 Not tainted 5.17.0-rc4-syzkaller #0 Nombre de hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 • https://git.kernel.org/stable/c/8f840e47f190cbe61a96945c13e9551048d42cef https://git.kernel.org/stable/c/3fc0fd724d199e061432b66a8d85b7d48fe485f7 https://git.kernel.org/stable/c/41a2864cf719c17294f417726edd411643462ab8 https://git.kernel.org/stable/c/2d8fa3fdf4542a2174a72d92018f488d65d848c5 https://git.kernel.org/stable/c/bbf59d7ae558940cfa2b36a287fd1e88d83f89f8 https://git.kernel.org/stable/c/b7e4d9ba2ddb78801488b4c623875b81fb46b545 https://git.kernel.org/stable/c/1502f15b9f29c41883a6139f2923523873282a83 https://git.kernel.org/stable/c/d828b0fe6631f3ae8709ac9a10c77c583 • CWE-401: Missing Release of Memory after Effective Lifetime •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48853 – swiotlb: fix info leak with DMA_FROM_DEVICE
https://notcve.org/view.php?id=CVE-2022-48853
In the Linux kernel, the following vulnerability has been resolved: swiotlb: fix info leak with DMA_FROM_DEVICE The problem I'm addressing was discovered by the LTP test covering cve-2018-1000204. A short description of what happens follows: 1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV and a corresponding dxferp. The peculiar thing about this is that TUR is not reading from the device. 2) In sg_start_req() the invocation of blk_rq_map_user() effectively bounces the user-space buffer. As if the device was to transfer into it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()") we make sure this first bounce buffer is allocated with GFP_ZERO. 3) For the rest of the story we keep ignoring that we have a TUR, so the device won't touch the buffer we prepare as if the we had a DMA_FROM_DEVICE type of situation. My setup uses a virtio-scsi device and the buffer allocated by SG is mapped by the function virtqueue_add_split() which uses DMA_FROM_DEVICE for the "in" sgs (here scatter-gather and not scsi generics). • https://git.kernel.org/stable/c/c132f2ba716b5ee6b35f82226a6e5417d013d753 https://git.kernel.org/stable/c/971e5dadffd02beba1063e7dd9c3a82de17cf534 https://git.kernel.org/stable/c/8d9ac1b6665c73f23e963775f85d99679fd8e192 https://git.kernel.org/stable/c/6bfc5377a210dbda2a237f16d94d1bd4f1335026 https://git.kernel.org/stable/c/d4d975e7921079f877f828099bb8260af335508f https://git.kernel.org/stable/c/7403f4118ab94be837ab9d770507537a8057bc63 https://git.kernel.org/stable/c/270475d6d2410ec66e971bf181afe1958dad565e https://git.kernel.org/stable/c/ddbd89deb7d32b1fbb879f48d68fda1a8 •
CVSS: 3.3EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48852 – drm/vc4: hdmi: Unregister codec device on unbind
https://notcve.org/view.php?id=CVE-2022-48852
In the Linux kernel, the following vulnerability has been resolved: drm/vc4: hdmi: Unregister codec device on unbind On bind we will register the HDMI codec device but we don't unregister it on unbind, leading to a device leakage. Unregister our device at unbind. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/vc4: hdmi: Anular el registro del dispositivo códec al desvincular. Al vincular, registraremos el dispositivo códec HDMI pero no lo cancelaremos al desvincular, lo que provoca una fuga del dispositivo. Dar de baja nuestro dispositivo en unbind. • https://git.kernel.org/stable/c/ee22082c3e2f230028afa0e22aa8773b1de3c919 https://git.kernel.org/stable/c/1ed68d776246f167aee9cd79f63f089c40a5e2a3 https://git.kernel.org/stable/c/e40945ab7c7f966d0c37b7bd7b0596497dfe228d •
CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48851 – staging: gdm724x: fix use after free in gdm_lte_rx()
https://notcve.org/view.php?id=CVE-2022-48851
In the Linux kernel, the following vulnerability has been resolved: staging: gdm724x: fix use after free in gdm_lte_rx() The netif_rx_ni() function frees the skb so we can't dereference it to save the skb->len. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: staging: gdm724x: corrige el use after free en gdm_lte_rx() La función netif_rx_ni() libera el skb para que no podamos desreferenciarlo para guardar el skb->len. • https://git.kernel.org/stable/c/61e121047645122c47714fcda684d0ee67f444af https://git.kernel.org/stable/c/6dc7b87c62423bfa68139fe95e85028aab584c9a https://git.kernel.org/stable/c/83a9c886c2b5a0d28c0b37e1736b47f38d61332a https://git.kernel.org/stable/c/48ecdf3e29a6e514e8196691589c7dfc6c4ac169 https://git.kernel.org/stable/c/403e3afe241b62401de1f8629c9c6b9b3d69dbff https://git.kernel.org/stable/c/6d9700b445098dbbce0caff4b8cfca214cf1e757 https://git.kernel.org/stable/c/1fb9dd3787495b4deb0efe66c58306b65691a48f https://git.kernel.org/stable/c/d39dc79513e99147b4c158a8a9e46743e • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48850 – net-sysfs: add check for netdevice being present to speed_show
https://notcve.org/view.php?id=CVE-2022-48850
In the Linux kernel, the following vulnerability has been resolved: net-sysfs: add check for netdevice being present to speed_show When bringing down the netdevice or system shutdown, a panic can be triggered while accessing the sysfs path because the device is already removed. [ 755.549084] mlx5_core 0000:12:00.1: Shutdown was called [ 756.404455] mlx5_core 0000:12:00.0: Shutdown was called ... [ 757.937260] BUG: unable to handle kernel NULL pointer dereference at (null) [ 758.031397] IP: [<ffffffff8ee11acb>] dma_pool_alloc+0x1ab/0x280 crash> bt ... PID: 12649 TASK: ffff8924108f2100 CPU: 1 COMMAND: "amsd" ... #9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778 [exception RIP: dma_pool_alloc+0x1ab] RIP: ffffffff8ee11acb RSP: ffff89240e1a3968 RFLAGS: 00010046 RAX: 0000000000000246 RBX: ffff89243d874100 RCX: 0000000000001000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff89243d874090 RBP: ffff89240e1a39c0 R8: 000000000001f080 R9: ffff8905ffc03c00 R10: ffffffffc04680d4 R11: ffffffff8edde9fd R12: 00000000000080d0 R13: ffff89243d874090 R14: ffff89243d874080 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core] #11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core] #12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core] #13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core] #14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core] #15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core] #16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core] #17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46 #18 [ffff89240e1a3d48] speed_show at ffffffff8f277208 #19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3 #20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf #21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596 #22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10 #23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5 #24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff #25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f #26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92 crash> net_device.state ffff89443b0c0000 state = 0x5 (__LINK_STATE_START| __LINK_STATE_NOCARRIER) To prevent this scenario, we also make sure that the netdevice is present. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net-sysfs: agregue verificación para que netdevice esté presente en speed_show Al desactivar el netdevice o apagar el sistema, se puede desencadenar un pánico al acceder a la ruta sysfs porque el dispositivo ya está eliminado. [ 755.549084] mlx5_core 0000:12:00.1: Se llamó al apagado [ 756.404455] mlx5_core 0000:12:00.0: Se llamó al apagado... [ 757.937260] ERROR: no se puede manejar la desreferencia del puntero NULL del kernel en (nulo) [ 758.031397] IP: [] dma_pool_alloc+0x1ab/0x280 crash> bt... PID: 12649 TAREA: ffff8924108f2100 CPU: 1 COMANDO: "amsd"... #9 [ffff89240e1a38b0] page_fault en ffffffff8f38c778 [excepción RIP: pool_alloc+0x1ab] RIP : ffffffff8ee11acb RSP: ffff89240e1a3968 RFLAGS: 00010046 RAX: 0000000000000246 RBX: ffff89243d874100 RCX: 0000000000001000 RDX: 00000000000000000 RSI: 0000000000000246 RDI: ffff89243d874090 RBP: ffff89240e1a39c0 R8: 000000000001f080 R9: ffff8905ffc03c00 R10: ffffffffc04680d4 R11: d R12: 00000000000080d0 R13: ffff89243d874090 R14: ffff89243d874080 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg en ffffffffc04680f3 [mlx5_core] #11 [ffff89240e1a3a18] d_exec en ffffffffc046ad62 [mlx5_core] #12 [ffff89240e1a3ab8] mlx5_cmd_exec en ffffffffc046b4fb [mlx5_core] #13 [ffff89240e1a3ae8] mlx5_core_access_reg en ffffffffc0475434 [mlx5_core] #14 [ffff89240e1a3b40] mlx5e_get_fec_caps en ffffffffc04a7348 [mlx5_core] #15 [ffff89240e1a3bb0] get_fec_supported_advertised en ffffffffc04992bf [mlx5_core] #16 [ffff89240e1a3c08] mlx5e_get_link_ksettings en ffffffffc049ab36 [mlx5_core] #17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings en ffffffff8f25db46 #18 [ ffff89240e1a3d48] speed_show en ffffffff8f277208 #19 [ffff89240e1a3dd8] dev_attr_show en ffffffff8f0b70e3 #20 [ffff89240e1a3df8] sysfs_kf_seq_show en ffffffff8eedbedf #21 40e1a3e18] kernfs_seq_show en ffffffff8eeda596 #22 [ffff89240e1a3e28] seq_read en ffffffff8ee76d10 #23 [ffff89240e1a3e98] kernfs_fop_read en ffffffff8eedaef5 #24 8] vfs_read en ffffffff8ee4e3ff #25 [ffff89240e1a3f08] sys_read en ffffffff8ee4f27f #26 [ffff89240e1a3f50] system_call_fastpath en ffffffff8f395f92 crash> net_device.state ffff89443b0c0000 estado = 0x5 LINK_STATE_START| __LINK_STATE_NOCARRIER) Para evitar este escenario, también nos aseguramos de que el netdevice esté presente. • https://git.kernel.org/stable/c/a7b9ab04c5932dee7ec95e0abc58b0df350c0dd2 https://git.kernel.org/stable/c/081369ad088a76429984483b8a5f7e967a125aad https://git.kernel.org/stable/c/75fc8363227a999e8f3d17e2eb28dce5600dcd3f https://git.kernel.org/stable/c/8879b5313e9fa5e0c6d6812a0d25d83aed0110e2 https://git.kernel.org/stable/c/d15c9f6e3335002fea1c33bc8f71a705fa96976c https://git.kernel.org/stable/c/8d5e69d8fbf3a35ab4fbe56b8f092802b43f3ef6 https://git.kernel.org/stable/c/3a79f380b3e10edf6caa9aac90163a5d7a282204 https://git.kernel.org/stable/c/4224cfd7fb6523f7a9d1c8bb91bb5df1e • CWE-476: NULL Pointer Dereference •