CVSS: 7.8EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48694 – RDMA/irdma: Fix drain SQ hang with no completion
https://notcve.org/view.php?id=CVE-2022-48694
In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix drain SQ hang with no completion SW generated completions for outstanding WRs posted on SQ after QP is in error target the wrong CQ. This causes the ib_drain_sq to hang with no completion. Fix this to generate completions on the right CQ. [ 863.969340] INFO: task kworker/u52:2:671 blocked for more than 122 seconds. [ 863.979224] Not tainted 5.14.0-130.el9.x86_64 #1 [ 863.986588] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 863.996997] task:kworker/u52:2 state:D stack: 0 pid: 671 ppid: 2 flags:0x00004000 [ 864.007272] Workqueue: xprtiod xprt_autoclose [sunrpc] [ 864.014056] Call Trace: [ 864.017575] __schedule+0x206/0x580 [ 864.022296] schedule+0x43/0xa0 [ 864.026736] schedule_timeout+0x115/0x150 [ 864.032185] __wait_for_common+0x93/0x1d0 [ 864.037717] ? usleep_range_state+0x90/0x90 [ 864.043368] __ib_drain_sq+0xf6/0x170 [ib_core] [ 864.049371] ? __rdma_block_iter_next+0x80/0x80 [ib_core] [ 864.056240] ib_drain_sq+0x66/0x70 [ib_core] [ 864.062003] rpcrdma_xprt_disconnect+0x82/0x3b0 [rpcrdma] [ 864.069365] ? xprt_prepare_transmit+0x5d/0xc0 [sunrpc] [ 864.076386] xprt_rdma_close+0xe/0x30 [rpcrdma] [ 864.082593] xprt_autoclose+0x52/0x100 [sunrpc] [ 864.088718] process_one_work+0x1e8/0x3c0 [ 864.094170] worker_thread+0x50/0x3b0 [ 864.099109] ? • https://git.kernel.org/stable/c/81091d7696ae71627ff80bbf2c6b0986d2c1cce3 https://git.kernel.org/stable/c/5becc531a3fa8da75158a8993f56cc3e0717716e https://git.kernel.org/stable/c/ead54ced6321099978d30d62dc49c282a6e70574 https://git.kernel.org/stable/c/14d148401c5202fec3a071e24785481d540b22c3 •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2022-48693 – soc: brcmstb: pm-arm: Fix refcount leak and __iomem leak bugs
https://notcve.org/view.php?id=CVE-2022-48693
In the Linux kernel, the following vulnerability has been resolved: soc: brcmstb: pm-arm: Fix refcount leak and __iomem leak bugs In brcmstb_pm_probe(), there are two kinds of leak bugs: (1) we need to add of_node_put() when for_each__matching_node() breaks (2) we need to add iounmap() for each iomap in fail path En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: brcmstb: pm-arm: corrige los errores de fuga de refcount y __iomem En brcmstb_pm_probe(), hay dos tipos de errores de fuga: (1) necesitamos agregar of_node_put() cuando for_each__matching_node() se rompe (2) necesitamos agregar iounmap() para cada iomap en la ruta de error • https://git.kernel.org/stable/c/0b741b8234c86065fb6954d32d427b3f7e14756f https://git.kernel.org/stable/c/0284b4e6dec6088a41607aa3f42bf51edff01883 https://git.kernel.org/stable/c/57b2897ec3ffe4cbe018446be6d04432919dca6b https://git.kernel.org/stable/c/6dc0251638a4a1a998506dbd4627f8317e907558 https://git.kernel.org/stable/c/43245c77d9efd8c9eb91bf225d07954dcf32204d https://git.kernel.org/stable/c/653500b400d5576940b7429690f7197199ddcc82 https://git.kernel.org/stable/c/1085f5080647f0c9f357c270a537869191f7f2a1 • CWE-401: Missing Release of Memory after Effective Lifetime •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48692 – RDMA/srp: Set scmnd->result only when scmnd is not NULL
https://notcve.org/view.php?id=CVE-2022-48692
In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: Set scmnd->result only when scmnd is not NULL This change fixes the following kernel NULL pointer dereference which is reproduced by blktests srp/007 occasionally. BUG: kernel NULL pointer dereference, address: 0000000000000170 PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1H Kdump: loaded Not tainted 6.0.0-rc1+ #37 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.15.0-29-g6a62e0cb0dfe-prebuilt.qemu.org 04/01/2014 Workqueue: 0x0 (kblockd) RIP: 0010:srp_recv_done+0x176/0x500 [ib_srp] Code: 00 4d 85 ff 0f 84 52 02 00 00 48 c7 82 80 02 00 00 00 00 00 00 4c 89 df 4c 89 14 24 e8 53 d3 4a f6 4c 8b 14 24 41 0f b6 42 13 <41> 89 87 70 01 00 00 41 0f b6 52 12 f6 c2 02 74 44 41 8b 42 1c b9 RSP: 0018:ffffaef7c0003e28 EFLAGS: 00000282 RAX: 0000000000000000 RBX: ffff9bc9486dea60 RCX: 0000000000000000 RDX: 0000000000000102 RSI: ffffffffb76bbd0e RDI: 00000000ffffffff RBP: ffff9bc980099a00 R08: 0000000000000001 R09: 0000000000000001 R10: ffff9bca53ef0000 R11: ffff9bc980099a10 R12: ffff9bc956e14000 R13: ffff9bc9836b9cb0 R14: ffff9bc9557b4480 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff9bc97ec00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000170 CR3: 0000000007e04000 CR4: 00000000000006f0 Call Trace: <IRQ> __ib_process_cq+0xb7/0x280 [ib_core] ib_poll_handler+0x2b/0x130 [ib_core] irq_poll_softirq+0x93/0x150 __do_softirq+0xee/0x4b8 irq_exit_rcu+0xf7/0x130 sysvec_apic_timer_interrupt+0x8e/0xc0 </IRQ> En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/srp: establezca scmnd->result solo cuando scmnd no sea NULL. Este cambio corrige la siguiente desreferencia del puntero NULL del kernel que blktests srp/007 reproduce ocasionalmente. ERROR: desreferencia del puntero NULL del kernel, dirección: 00000000000000170 PGD 0 P4D 0 Ups: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1H Kdump: cargado No contaminado 6.0.0-rc1+ #37 Hardware nombre: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.15.0-29-g6a62e0cb0dfe-prebuilt.qemu.org 01/04/2014 Cola de trabajo: 0x0 (kblockd) RIP: 0010:srp_recv_done+0x176/0x500 [ ib_srp] Código: 00 4d 85 ff 0f 84 52 02 00 00 48 c7 82 80 02 00 00 00 00 00 00 4c 89 df 4c 89 14 24 e8 53 d3 4a f6 4c 8b 14 24 41 0f b6 2 13 <41> 89 87 70 01 00 00 41 0f b6 52 12 f6 c2 02 74 44 41 8b 42 1c b9 RSP: 0018:ffffaef7c0003e28 EFLAGS: 00000282 RAX: 0000000000000000 RBX: ffff9bc94 86dea60 RCX: 0000000000000000 RDX: 00000000000000102 RSI: ffffffffb76bbd0e RDI: 00000000ffffffff RBP: ffff9bc980099a00 R08 : 0000000000000001 R09: 0000000000000001 R10: ffff9bca53ef0000 R11: ffff9bc980099a10 R12: ffff9bc956e14000 R13: ffff9bc9836b9cb0 R14: 4480 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff9bc97ec00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 080050033 CR2: 0000000000000170 CR3: 0000000007e04000 CR4: 00000000000006f0 Seguimiento de llamadas: __ib_process_cq+0xb7/0x280 [ib_core] ib_poll_handler+0x2b/0x130 [ib_core] q+0x93/0x150 __do_softirq+0xee/0x4b8 irq_exit_rcu+0xf7/0x130 sysvec_apic_timer_interrupt+0x8e/ 0xc0 • https://git.kernel.org/stable/c/ad215aaea4f9d637f441566cdbbc610e9849e1fa https://git.kernel.org/stable/c/a8edd49c94b4b08019ed7d6dd794fca8078a4deb https://git.kernel.org/stable/c/f2c70f56f762e5dc3b0d7dc438fbb137cb116413 https://git.kernel.org/stable/c/12f35199a2c0551187edbf8eb01379f0598659fa https://git.kernel.org/stable/c/f022576aa03c2385ea7f2b27ee5b331e43abf624 • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48691 – netfilter: nf_tables: clean up hook list when offload flags check fails
https://notcve.org/view.php?id=CVE-2022-48691
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: clean up hook list when offload flags check fails splice back the hook list so nft_chain_release_hook() has a chance to release the hooks. BUG: memory leak unreferenced object 0xffff88810180b100 (size 96): comm "syz-executor133", pid 3619, jiffies 4294945714 (age 12.690s) hex dump (first 32 bytes): 28 64 23 02 81 88 ff ff 28 64 23 02 81 88 ff ff (d#.....(d#..... 90 a8 aa 83 ff ff ff ff 00 00 b5 0f 81 88 ff ff ................ backtrace: [<ffffffff83a8c59b>] kmalloc include/linux/slab.h:600 [inline] [<ffffffff83a8c59b>] nft_netdev_hook_alloc+0x3b/0xc0 net/netfilter/nf_tables_api.c:1901 [<ffffffff83a9239a>] nft_chain_parse_netdev net/netfilter/nf_tables_api.c:1998 [inline] [<ffffffff83a9239a>] nft_chain_parse_hook+0x33a/0x530 net/netfilter/nf_tables_api.c:2073 [<ffffffff83a9b14b>] nf_tables_addchain.constprop.0+0x10b/0x950 net/netfilter/nf_tables_api.c:2218 [<ffffffff83a9c41b>] nf_tables_newchain+0xa8b/0xc60 net/netfilter/nf_tables_api.c:2593 [<ffffffff83a3d6a6>] nfnetlink_rcv_batch+0xa46/0xd20 net/netfilter/nfnetlink.c:517 [<ffffffff83a3db79>] nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:638 [inline] [<ffffffff83a3db79>] nfnetlink_rcv+0x1f9/0x220 net/netfilter/nfnetlink.c:656 [<ffffffff83a13b17>] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] [<ffffffff83a13b17>] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345 [<ffffffff83a13fd6>] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921 [<ffffffff83865ab6>] sock_sendmsg_nosec net/socket.c:714 [inline] [<ffffffff83865ab6>] sock_sendmsg+0x56/0x80 net/socket.c:734 [<ffffffff8386601c>] ____sys_sendmsg+0x36c/0x390 net/socket.c:2482 [<ffffffff8386a918>] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536 [<ffffffff8386aaa8>] __sys_sendmsg+0x88/0x100 net/socket.c:2565 [<ffffffff845e5955>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff845e5955>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: limpia la lista de ganchos cuando falla la verificación de indicadores de descarga, vuelve a unir la lista de ganchos para que nft_chain_release_hook() tenga la oportunidad de liberar los ganchos. ERROR: pérdida de memoria objeto sin referencia 0xffff88810180b100 (tamaño 96): comunicación "syz-executor133", pid 3619, jiffies 4294945714 (edad 12.690 s) volcado hexadecimal (primeros 32 bytes): 28 64 23 02 81 88 ff ff 28 64 02 81 88 ff ff (d#.....(d#..... 90 a8 aa 83 ff ff ff ff 00 00 b5 0f 81 88 ff ff ................ retroceso : [] kmalloc include/linux/slab.h:600 [en línea] [] nft_netdev_hook_alloc+0x3b/0xc0 net/netfilter/nf_tables_api.c:1901 [] netdev net/netfilter/nf_tables_api. c:1998 [en línea] [] nft_chain_parse_hook+0x33a/0x530 net/netfilter/nf_tables_api.c:2073 [] nf_tables_addchain.constprop.0+0x10b/0x950 f_tables_api.c:2218 [< ffffffff83a9c41b>] nf_tables_newchain+0xa8b/0xc60 net/netfilter/nf_tables_api.c:2593 [] nfnetlink_rcv_batch+0xa46/0xd20 net/netfilter/nfnetlink.c:517 [] nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c: 638 [en línea] [] nfnetlink_rcv+0x1f9/0x220 net/netfilter/nfnetlink.c:656 [] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [en línea] [] emitir+0x397/ 0x4c0 net/netlink/af_netlink.c:1345 [] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921 [] sock_sendmsg_nosec net/socket.c:714 [en línea] 65ab6>] sock_sendmsg+0x56/0x80 net/socket.c:734 [] ____sys_sendmsg+0x36c/0x390 net/socket.c:2482 [] ___sys_sendmsg+0xa8/0x110 36 [ ] __sys_sendmsg+0x88/0x100 net/socket.c:2565 [] do_syscall_x64 arch/x86/entry/common.c:50 [en línea] [] do_syscall_64+0x35/0xb0 arch/x86/ent ry/común .c:80 [] entrada_SYSCALL_64_after_hwframe+0x63/0xcd • https://git.kernel.org/stable/c/d54725cd11a57c30f650260cfb0a92c268bdc3e0 https://git.kernel.org/stable/c/910891a2a44cdc49efcc4fe7459c1085ba00d0f4 https://git.kernel.org/stable/c/1ce55ec5cb7c573c983dffbe290b8d17caf1f157 https://git.kernel.org/stable/c/94ed8eeb8d9aeb00e4f4e19b83a2e28b6442fbc5 https://git.kernel.org/stable/c/77972a36ecc4db7fc7c68f0e80714263c5f03f65 • CWE-401: Missing Release of Memory after Effective Lifetime •
CVSS: 7.0EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48689 – tcp: TX zerocopy should not sense pfmemalloc status
https://notcve.org/view.php?id=CVE-2022-48689
In the Linux kernel, the following vulnerability has been resolved: tcp: TX zerocopy should not sense pfmemalloc status We got a recent syzbot report [1] showing a possible misuse of pfmemalloc page status in TCP zerocopy paths. Indeed, for pages coming from user space or other layers, using page_is_pfmemalloc() is moot, and possibly could give false positives. There has been attempts to make page_is_pfmemalloc() more robust, but not using it in the first place in this context is probably better, removing cpu cycles. Note to stable teams : You need to backport 84ce071e38a6 ("net: introduce __skb_fill_page_desc_noacc") as a prereq. Race is more probable after commit c07aea3ef4d4 ("mm: add a signature in struct page") because page_is_pfmemalloc() is now using low order bit from page->lru.next, which can change more often than page->index. Low order bit should never be set for lru.next (when used as an anchor in LRU list), so KCSAN report is mostly a false positive. Backporting to older kernel versions seems not necessary. [1] BUG: KCSAN: data-race in lru_add_fn / tcp_build_frag write to 0xffffea0004a1d2c8 of 8 bytes by task 18600 on cpu 0: __list_add include/linux/list.h:73 [inline] list_add include/linux/list.h:88 [inline] lruvec_add_folio include/linux/mm_inline.h:105 [inline] lru_add_fn+0x440/0x520 mm/swap.c:228 folio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246 folio_batch_add_and_move mm/swap.c:263 [inline] folio_add_lru+0xf1/0x140 mm/swap.c:490 filemap_add_folio+0xf8/0x150 mm/filemap.c:948 __filemap_get_folio+0x510/0x6d0 mm/filemap.c:1981 pagecache_get_page+0x26/0x190 mm/folio-compat.c:104 grab_cache_page_write_begin+0x2a/0x30 mm/folio-compat.c:116 ext4_da_write_begin+0x2dd/0x5f0 fs/ext4/inode.c:2988 generic_perform_write+0x1d4/0x3f0 mm/filemap.c:3738 ext4_buffered_write_iter+0x235/0x3e0 fs/ext4/file.c:270 ext4_file_write_iter+0x2e3/0x1210 call_write_iter include/linux/fs.h:2187 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x468/0x760 fs/read_write.c:578 ksys_write+0xe8/0x1a0 fs/read_write.c:631 __do_sys_write fs/read_write.c:643 [inline] __se_sys_write fs/read_write.c:640 [inline] __x64_sys_write+0x3e/0x50 fs/read_write.c:640 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd read to 0xffffea0004a1d2c8 of 8 bytes by task 18611 on cpu 1: page_is_pfmemalloc include/linux/mm.h:1740 [inline] __skb_fill_page_desc include/linux/skbuff.h:2422 [inline] skb_fill_page_desc include/linux/skbuff.h:2443 [inline] tcp_build_frag+0x613/0xb20 net/ipv4/tcp.c:1018 do_tcp_sendpages+0x3e8/0xaf0 net/ipv4/tcp.c:1075 tcp_sendpage_locked net/ipv4/tcp.c:1140 [inline] tcp_sendpage+0x89/0xb0 net/ipv4/tcp.c:1150 inet_sendpage+0x7f/0xc0 net/ipv4/af_inet.c:833 kernel_sendpage+0x184/0x300 net/socket.c:3561 sock_sendpage+0x5a/0x70 net/socket.c:1054 pipe_to_sendpage+0x128/0x160 fs/splice.c:361 splice_from_pipe_feed fs/splice.c:415 [inline] __splice_from_pipe+0x222/0x4d0 fs/splice.c:559 splice_from_pipe fs/splice.c:594 [inline] generic_splice_sendpage+0x89/0xc0 fs/splice.c:743 do_splice_from fs/splice.c:764 [inline] direct_splice_actor+0x80/0xa0 fs/splice.c:931 splice_direct_to_actor+0x305/0x620 fs/splice.c:886 do_splice_direct+0xfb/0x180 fs/splice.c:974 do_sendfile+0x3bf/0x910 fs/read_write.c:1249 __do_sys_sendfile64 fs/read_write.c:1317 [inline] __se_sys_sendfile64 fs/read_write.c:1303 [inline] __x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1303 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x0000000000000000 -> 0xffffea0004a1d288 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 18611 Comm: syz-executor.4 Not tainted 6.0.0-rc2-syzkaller-00248-ge022620b5d05-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tcp: TX zerocopy no debería detectar el estado de pfmemalloc Recibimos un informe reciente de syzbot [1] que muestra un posible uso indebido del estado de la página pfmemalloc en rutas de TCP zerocopy. De hecho, para páginas provenientes del espacio de usuario u otras capas, usar page_is_pfmemalloc() es discutible y posiblemente podría dar falsos positivos. Ha habido intentos de hacer que page_is_pfmemalloc() sea más robusto, pero probablemente sea mejor no usarlo en primer lugar en este contexto, ya que elimina los ciclos de la CPU. Nota para los equipos estables: deben respaldar 84ce071e38a6 ("net: introduzca __skb_fill_page_desc_noacc") como requisito previo. La carrera es más probable después de confirmar c07aea3ef4d4 ("mm: agregar una firma en la página de estructura") porque page_is_pfmemalloc() ahora usa un bit de orden bajo de página->lru.next, que puede cambiar con más frecuencia que página->índice. • https://git.kernel.org/stable/c/c07aea3ef4d4076f18f567b98ed01e082e02ed51 https://git.kernel.org/stable/c/8527c9a6bf8e54fef0a8d3d7d8874a48c725c915 https://git.kernel.org/stable/c/6730c48ed6b0cd939fc9b30b2d621ce0b89bea83 https://git.kernel.org/stable/c/3261400639463a853ba2b3be8bd009c2a8089775 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •