CVSS: 4.7EPSS: 0%CPEs: 3EXPL: 0CVE-2021-46925 – net/smc: fix kernel panic caused by race of smc_sock
https://notcve.org/view.php?id=CVE-2021-46925
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix kernel panic caused by race of smc_sock A crash occurs when smc_cdc_tx_handler() tries to access smc_sock but smc_release() has already freed it. [ 4570.695099] BUG: unable to handle page fault for address: 000000002eae9e88 [ 4570.696048] #PF: supervisor write access in kernel mode [ 4570.696728] #PF: error_code(0x0002) - not-present page [ 4570.697401] PGD 0 P4D 0 [ 4570.697716] Oops: 0002 [#1] PREEMPT SMP NOPTI [ 4570.698228] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.16.0-rc4+ #111 [ 4570.699013] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 8c24b4c 04/0 [ 4570.699933] RIP: 0010:_raw_spin_lock+0x1a/0x30 <...> [ 4570.711446] Call Trace: [ 4570.711746] <IRQ> [ 4570.711992] smc_cdc_tx_handler+0x41/0xc0 [ 4570.712470] smc_wr_tx_tasklet_fn+0x213/0x560 [ 4570.712981] ? smc_cdc_tx_dismisser+0x10/0x10 [ 4570.713489] tasklet_action_common.isra.17+0x66/0x140 [ 4570.714083] __do_softirq+0x123/0x2f4 [ 4570.714521] irq_exit_rcu+0xc4/0xf0 [ 4570.714934] common_interrupt+0xba/0xe0 Though smc_cdc_tx_handler() checked the existence of smc connection, smc_release() may have already dismissed and released the smc socket before smc_cdc_tx_handler() further visits it. smc_cdc_tx_handler() |smc_release() if (!conn) | | |smc_cdc_tx_dismiss_slots() | smc_cdc_tx_dismisser() | |sock_put(&smc->sk) <- last sock_put, | smc_sock freed bh_lock_sock(&smc->sk) (panic) | To make sure we won't receive any CDC messages after we free the smc_sock, add a refcount on the smc_connection for inflight CDC message(posted to the QP but haven't received related CQE), and don't release the smc_connection until all the inflight CDC messages haven been done, for both success or failed ones. Using refcount on CDC messages brings another problem: when the link is going to be destroyed, smcr_link_clear() will reset the QP, which then remove all the pending CQEs related to the QP in the CQ. To make sure all the CQEs will always come back so the refcount on the smc_connection can always reach 0, smc_ib_modify_qp_reset() was replaced by smc_ib_modify_qp_error(). And remove the timeout in smc_wr_tx_wait_no_pending_sends() since we need to wait for all pending WQEs done, or we may encounter use-after- free when handling CQEs. For IB device removal routine, we need to wait for all the QPs on that device been destroyed before we can destroy CQs on the device, or the refcount on smc_connection won't reach 0 and smc_sock cannot be released. • https://git.kernel.org/stable/c/5f08318f617b05b6ee389d8bd174c7af921ebf19 https://git.kernel.org/stable/c/e8a5988a85c719ce7205cb00dcf0716dcf611332 https://git.kernel.org/stable/c/b85f751d71ae8e2a15e9bda98852ea9af35282eb https://git.kernel.org/stable/c/349d43127dac00c15231e8ffbcaabd70f7b0e544 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2021-46924 – NFC: st21nfca: Fix memory leak in device probe and remove
https://notcve.org/view.php?id=CVE-2021-46924
In the Linux kernel, the following vulnerability has been resolved: NFC: st21nfca: Fix memory leak in device probe and remove 'phy->pending_skb' is alloced when device probe, but forgot to free in the error handling path and remove path, this cause memory leak as follows: unreferenced object 0xffff88800bc06800 (size 512): comm "8", pid 11775, jiffies 4295159829 (age 9.032s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000d66c09ce>] __kmalloc_node_track_caller+0x1ed/0x450 [<00000000c93382b3>] kmalloc_reserve+0x37/0xd0 [<000000005fea522c>] __alloc_skb+0x124/0x380 [<0000000019f29f9a>] st21nfca_hci_i2c_probe+0x170/0x8f2 Fix it by freeing 'pending_skb' in error and remove. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: NFC: st21nfca: corrige la pérdida de memoria en la sonda del dispositivo y elimina 'phy->pending_skb' cuando se asigna la sonda del dispositivo, pero olvidó liberarla en la ruta de manejo de errores y eliminar la ruta, esto causa pérdida de memoria de la siguiente manera: objeto sin referencia 0xffff88800bc06800 (tamaño 512): comunicación "8", pid 11775, santiago 4295159829 (edad 9.032 s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................. backtrace: [<00000000d66c09ce>] __kmalloc_node_track_caller+0x1ed/0x450 [<00000000c93382b3>] kmalloc_reserve+0x37/0xd0 [<000000005fea522c>] __alloc_skb+0x124/0x380 [ <0000000019f29f9a>] st21nfca_hci_i2c_probe+0x170/0x8f2 Solucionarlo liberando 'pending_skb' por error y elimínelo. • https://git.kernel.org/stable/c/68957303f44a501af5cf37913208a2acaa6bcdf1 https://git.kernel.org/stable/c/38c3e320e7ff46f2dc67bc5045333e63d9f8918d https://git.kernel.org/stable/c/a1e0080a35a16ce3808f7040fe0c3a8fdb052349 https://git.kernel.org/stable/c/1cd4063dbc91cf7965d73a6a3855e2028cd4613b https://git.kernel.org/stable/c/e553265ea56482da5700f56319fda9ff53e7dcb4 https://git.kernel.org/stable/c/238920381b8925d070d32d73cd9ce52ab29896fe https://git.kernel.org/stable/c/1b9dadba502234eea7244879b8d5d126bfaf9f0c • CWE-401: Missing Release of Memory after Effective Lifetime •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2021-46915 – netfilter: nft_limit: avoid possible divide error in nft_limit_init
https://notcve.org/view.php?id=CVE-2021-46915
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_limit: avoid possible divide error in nft_limit_init div_u64() divides u64 by u32. nft_limit_init() wants to divide u64 by u64, use the appropriate math function (div64_u64) divide error: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8390 Comm: syz-executor188 Not tainted 5.12.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:div_u64_rem include/linux/math64.h:28 [inline] RIP: 0010:div_u64 include/linux/math64.h:127 [inline] RIP: 0010:nft_limit_init+0x2a2/0x5e0 net/netfilter/nft_limit.c:85 Code: ef 4c 01 eb 41 0f 92 c7 48 89 de e8 38 a5 22 fa 4d 85 ff 0f 85 97 02 00 00 e8 ea 9e 22 fa 4c 0f af f3 45 89 ed 31 d2 4c 89 f0 <49> f7 f5 49 89 c6 e8 d3 9e 22 fa 48 8d 7d 48 48 b8 00 00 00 00 00 RSP: 0018:ffffc90009447198 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000200000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff875152e6 RDI: 0000000000000003 RBP: ffff888020f80908 R08: 0000200000000000 R09: 0000000000000000 R10: ffffffff875152d8 R11: 0000000000000000 R12: ffffc90009447270 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 000000000097a300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200001c4 CR3: 0000000026a52000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: nf_tables_newexpr net/netfilter/nf_tables_api.c:2675 [inline] nft_expr_init+0x145/0x2d0 net/netfilter/nf_tables_api.c:2713 nft_set_elem_expr_alloc+0x27/0x280 net/netfilter/nf_tables_api.c:5160 nf_tables_newset+0x1997/0x3150 net/netfilter/nf_tables_api.c:4321 nfnetlink_rcv_batch+0x85a/0x21b0 net/netfilter/nfnetlink.c:456 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:580 [inline] nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:598 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: netfilter: nft_limit: evita posible error de división en nft_limit_init div_u64() divide u64 entre u32. nft_limit_init() quiere dividir u64 entre u64, use la función matemática apropiada (div64_u64) error de división: 0000 [#1] CPU PREEMPT SMP KASAN: 1 PID: 8390 Comm: syz-executor188 Not tainted 5.12.0-rc4-syzkaller # 0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:div_u64_rem include/linux/math64.h:28 [en línea] RIP: 0010:div_u64 include/linux/math64.h: 127 [en línea] RIP: 0010:nft_limit_init+0x2a2/0x5e0 net/netfilter/nft_limit.c:85 Código: ef 4c 01 eb 41 0f 92 c7 48 89 de e8 38 a5 22 fa 4d 85 ff 0f 85 97 02 00 00 e8 ea 9e 22 fa 4c 0f af f3 45 89 ed 31 d2 4c 89 f0 <49> f7 f5 49 89 c6 e8 d3 9e 22 fa 48 8d 7d 48 48 b8 00 00 00 00 00 RSP: 0018:ffffc90009447198 EF LAGS: 00010246 RAX: 0000000000000000 RBX: 0000200000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff875152e6 RDI: 0000000000000003 RBP: ffff888 020f80908 R08: 0000200000000000 R09: 0000000000000000 R10: ffffffff875152d8 R11: 0000000000000000 R12: ffffc90009447270 R13: 000000000000 0000 R14: 0000000000000000 R15: 0000000000000000 FS: 000000000097a300(0000) GS :ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200001c4 CR3: 0000000026a52000 CR 4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 00000000000000000 DR6: 00000000ffe0ff0 DR7: 00000 00000000400 Rastreo de llamadas: nf_tables_newexpr net/netfilter/nf_tables_api.c:2675 [en línea] nft_expr_init+0x145/0x2d0 net/netfilter/nf_tables_api.c:2713 nft_set_elem_expr_alloc+0x27/0x280 net/netfilter/nf_tables_api.c:5160 nf_tables_newset+0x1997/0x3150 net/netfilter/ nf_tables_api.c:4321 nfnetlink_rcv_batch+0x85a/0x21b0 net/netfilter/nfnetlink.c:456 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:580 [en línea] nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:59 8 netlink_unicast_kernel red/netlink /af_netlink.c:1312 [en línea] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [en línea] sock_sendmsg+ 0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_sys llamada_64+0x2d/ 0x70 arch/x86/entry/common.c:46 entrada_SYSCALL_64_after_hwframe+0x44/0xae A denial of service flaw was found in nft_limit_init in netfilter's nft_limit in the Linux Kernel. This issue occurs due to an inappropriate math function selection, which may cause an availability threat. • https://git.kernel.org/stable/c/c26844eda9d4fdbd266660e3b3de2d0270e3a1ed https://git.kernel.org/stable/c/9065ccb9ec92c5120e7e97958397ebdb454f23d6 https://git.kernel.org/stable/c/fadd3c4afdf3d4c21f4d138502f8b76334987e26 https://git.kernel.org/stable/c/01fb1626b620cb37a65ad08e0f626489e8f042ef https://git.kernel.org/stable/c/dc1732baa9da5b68621586bf8636ebbc27dc62d2 https://git.kernel.org/stable/c/1bb3ee4259936cc3b2d80a4a480bbb4868575071 https://git.kernel.org/stable/c/b895bdf5d643b6feb7c60856326dd4feb6981560 https://access.redhat.com/security/cve/CVE-2021-46915 • CWE-369: Divide By Zero •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2021-46909 – ARM: footbridge: fix PCI interrupt mapping
https://notcve.org/view.php?id=CVE-2021-46909
In the Linux kernel, the following vulnerability has been resolved: ARM: footbridge: fix PCI interrupt mapping Since commit 30fdfb929e82 ("PCI: Add a call to pci_assign_irq() in pci_device_probe()"), the PCI code will call the IRQ mapping function whenever a PCI driver is probed. If these are marked as __init, this causes an oops if a PCI driver is loaded or bound after the kernel has initialised. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: footbridge: corrige el mapeo de interrupciones PCI Desde el commit 30fdfb929e82 ("PCI: agregue una llamada a pci_assign_irq() en pci_device_probe()"), el código PCI llamará a la función de mapeo IRQ cada vez que se prueba un controlador PCI. Si están marcados como __init, esto provoca un error si se carga o enlaza un controlador PCI después de que el kernel se haya inicializado. • https://git.kernel.org/stable/c/30fdfb929e82450bbf3d0e0aba56efbc29b52b52 https://git.kernel.org/stable/c/532747fd5c7aaa17ee5cf79f3e947c31eb0e35cf https://git.kernel.org/stable/c/2643da6aa57920d9159a1a579fb04f89a2b0d29a https://git.kernel.org/stable/c/871b569a3e67f570df9f5ba195444dc7c621293b https://git.kernel.org/stable/c/1fc087fdb98d556b416c82ed6e3964a30885f47a https://git.kernel.org/stable/c/c3efce8cc9807339633ee30e39882f4c8626ee1d https://git.kernel.org/stable/c/30e3b4f256b4e366a61658c294f6a21b8626dda7 https://access.redhat.com/security/cve/CVE-2021-46909 • CWE-391: Unchecked Error Condition CWE-754: Improper Check for Unusual or Exceptional Conditions •
CVSS: 7.8EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52474 – IB/hfi1: Fix bugs with non-PAGE_SIZE-end multi-iovec user SDMA requests
https://notcve.org/view.php?id=CVE-2023-52474
In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix bugs with non-PAGE_SIZE-end multi-iovec user SDMA requests hfi1 user SDMA request processing has two bugs that can cause data corruption for user SDMA requests that have multiple payload iovecs where an iovec other than the tail iovec does not run up to the page boundary for the buffer pointed to by that iovec.a Here are the specific bugs: 1. user_sdma_txadd() does not use struct user_sdma_iovec->iov.iov_len. Rather, user_sdma_txadd() will add up to PAGE_SIZE bytes from iovec to the packet, even if some of those bytes are past iovec->iov.iov_len and are thus not intended to be in the packet. 2. user_sdma_txadd() and user_sdma_send_pkts() fail to advance to the next iovec in user_sdma_request->iovs when the current iovec is not PAGE_SIZE and does not contain enough data to complete the packet. The transmitted packet will contain the wrong data from the iovec pages. This has not been an issue with SDMA packets from hfi1 Verbs or PSM2 because they only produce iovecs that end short of PAGE_SIZE as the tail iovec of an SDMA request. Fixing these bugs exposes other bugs with the SDMA pin cache (struct mmu_rb_handler) that get in way of supporting user SDMA requests with multiple payload iovecs whose buffers do not end at PAGE_SIZE. So this commit fixes those issues as well. Here are the mmu_rb_handler bugs that non-PAGE_SIZE-end multi-iovec payload user SDMA requests can hit: 1. Overlapping memory ranges in mmu_rb_handler will result in duplicate pinnings. 2. When extending an existing mmu_rb_handler entry (struct mmu_rb_node), the mmu_rb code (1) removes the existing entry under a lock, (2) releases that lock, pins the new pages, (3) then reacquires the lock to insert the extended mmu_rb_node. If someone else comes in and inserts an overlapping entry between (2) and (3), insert in (3) will fail. The failure path code in this case unpins _all_ pages in either the original mmu_rb_node or the new mmu_rb_node that was inserted between (2) and (3). 3. • https://git.kernel.org/stable/c/7724105686e718ac476a6ad3304fea2fbcfcffde https://git.kernel.org/stable/c/9c4c6512d7330b743c4ffd18bd999a86ca26db0d https://git.kernel.org/stable/c/a2bd706ab63509793b5cd5065e685b7ef5cba678 https://git.kernel.org/stable/c/dce59b5443700fbd0d2433ec6e4d4cf063448844 https://git.kernel.org/stable/c/c76cb8f4bdf26d04cfa5485a93ce297dba5e6a80 https://git.kernel.org/stable/c/7e6010f79b58f45b204cf18aa58f4b73c3f30adc https://git.kernel.org/stable/c/00cbce5cbf88459cd1aa1d60d0f1df15477df127 •