CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47005 – PCI: endpoint: Fix NULL pointer dereference for ->get_features()
https://notcve.org/view.php?id=CVE-2021-47005
In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Fix NULL pointer dereference for ->get_features() get_features ops of pci_epc_ops may return NULL, causing NULL pointer dereference in pci_epf_test_alloc_space function. Let us add a check for pci_epc_feature pointer in pci_epf_test_bind before we access it to avoid any such NULL pointer dereference and return -ENOTSUPP in case pci_epc_feature is not found. When the patch is not applied and EPC features is not implemented in the platform driver, we see the following dump due to kernel NULL pointer dereference. Call trace: pci_epf_test_bind+0xf4/0x388 pci_epf_bind+0x3c/0x80 pci_epc_epf_link+0xa8/0xcc configfs_symlink+0x1a4/0x48c vfs_symlink+0x104/0x184 do_symlinkat+0x80/0xd4 __arm64_sys_symlinkat+0x1c/0x24 el0_svc_common.constprop.3+0xb8/0x170 el0_svc_handler+0x70/0x88 el0_svc+0x8/0x640 Code: d2800581 b9403ab9 f9404ebb 8b394f60 (f9400400) ---[ end trace a438e3c5a24f9df0 ]--- En el kernel de Linux, se resolvió la siguiente vulnerabilidad: PCI: endpoint: corrigió la desreferencia del puntero NULL para ->get_features() las operaciones get_features de pci_epc_ops pueden devolver NULL, lo que provoca la desreferencia del puntero NULL en la función pci_epf_test_alloc_space. Agreguemos una verificación del puntero pci_epc_feature en pci_epf_test_bind antes de acceder a él para evitar dicha desreferencia del puntero NULL y devolvamos -ENOTSUPP en caso de que no se encuentre pci_epc_feature. Cuando no se aplica el parche y las funciones de EPC no se implementan en el controlador de la plataforma, vemos el siguiente volcado debido a la desreferencia del puntero NULL del kernel. Rastreo de llamadas: pci_epf_test_bind+0xf4/0x388 pci_epf_bind+0x3c/0x80 pci_epc_epf_link+0xa8/0xcc configfs_symlink+0x1a4/0x48c vfs_symlink+0x104/0x184 do_symlinkat+0x80/0xd4 __arm64_sys _symlinkat+0x1c/0x24 el0_svc_common.constprop.3+0xb8/0x170 el0_svc_handler+0x70 /0x88 el0_svc+0x8/0x640 Código: d2800581 b9403ab9 f9404ebb 8b394f60 (f9400400) ---[ final de seguimiento a438e3c5a24f9df0 ]--- • https://git.kernel.org/stable/c/2c04c5b8eef797dca99699cfb55ff42dd3c12c23 https://git.kernel.org/stable/c/bbed83d7060e07a5d309104d25a00f0a24441428 https://git.kernel.org/stable/c/679ebad058b8168f10e63876d63b0877fd2fe784 https://git.kernel.org/stable/c/0169d4f0bee44fdfef908c13ed21fcb326c38695 https://git.kernel.org/stable/c/6613bc2301ba291a1c5a90e1dc24cf3edf223c03 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47004 – f2fs: fix to avoid touching checkpointed data in get_victim()
https://notcve.org/view.php?id=CVE-2021-47004
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid touching checkpointed data in get_victim() In CP disabling mode, there are two issues when using LFS or SSR | AT_SSR mode to select victim: 1. LFS is set to find source section during GC, the victim should have no checkpointed data, since after GC, section could not be set free for reuse. Previously, we only check valid chpt blocks in current segment rather than section, fix it. 2. SSR | AT_SSR are set to find target segment for writes which can be fully filled by checkpointed and newly written blocks, we should never select such segment, otherwise it can cause panic or data corruption during allocation, potential case is described as below: a) target segment has 'n' (n < 512) ckpt valid blocks b) GC migrates 'n' valid blocks to other segment (segment is still in dirty list) c) GC migrates '512 - n' blocks to target segment (segment has 'n' cp_vblocks and '512 - n' vblocks) d) If GC selects target segment via {AT,}SSR allocator, however there is no free space in targe segment. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para evitar tocar datos con puntos de control en get_victim() En el modo de desactivación de CP, hay dos problemas al usar LFS o SSR | Modo AT_SSR para seleccionar a la víctima: 1. LFS está configurado para buscar la sección de origen durante la GC, la víctima no debe tener datos de puntos de control, ya que después de la GC, la sección no se puede liberar para su reutilización. • https://git.kernel.org/stable/c/4354994f097d068a894aa1a0860da54571df3582 https://git.kernel.org/stable/c/105155a8146ddb54c119d8318964eef3859d109d https://git.kernel.org/stable/c/1e116f87825f01a6380286472196882746b16f63 https://git.kernel.org/stable/c/211372b2571520e394b56b431a0705586013b3ff https://git.kernel.org/stable/c/61461fc921b756ae16e64243f72af2bfc2e620db •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47001 – xprtrdma: Fix cwnd update ordering
https://notcve.org/view.php?id=CVE-2021-47001
In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix cwnd update ordering After a reconnect, the reply handler is opening the cwnd (and thus enabling more RPC Calls to be sent) /before/ rpcrdma_post_recvs() can post enough Receive WRs to receive their replies. This causes an RNR and the new connection is lost immediately. The race is most clearly exposed when KASAN and disconnect injection are enabled. This slows down rpcrdma_rep_create() enough to allow the send side to post a bunch of RPC Calls before the Receive completion handler can invoke ib_post_recv(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: xprtrdma: corrige el orden de actualización de cwnd Después de una reconexión, el controlador de respuesta abre cwnd (y así permite que se envíen más llamadas RPC) /antes/ rpcrdma_post_recvs() puede publicar suficiente recepción WR para recibir sus respuestas. Esto provoca un RNR y la nueva conexión se pierde inmediatamente. • https://git.kernel.org/stable/c/2ae50ad68cd79224198b525f7bd645c9da98b6ff https://git.kernel.org/stable/c/3791c5982ba1eebf2900ee7ca7b9a89619c26d54 https://git.kernel.org/stable/c/eddae8be7944096419c2ae29477a45f767d0fcd4 https://git.kernel.org/stable/c/8834ecb5df22b7ff3c9b0deba7726579bb613f95 https://git.kernel.org/stable/c/19b5fa9489b5706bc878c3a522a7f771079e2fa0 https://git.kernel.org/stable/c/35d8b10a25884050bb3b0149b62c3818ec59f77c •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2021-47000 – ceph: fix inode leak on getattr error in __fh_to_dentry
https://notcve.org/view.php?id=CVE-2021-47000
In the Linux kernel, the following vulnerability has been resolved: ceph: fix inode leak on getattr error in __fh_to_dentry En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ceph: corrige la fuga de inodo en el error getattr en __fh_to_dentry • https://git.kernel.org/stable/c/807460787179dee5f74906965eeb5f3ca2353992 https://git.kernel.org/stable/c/878dabb64117406abd40977b87544d05bb3031fc https://git.kernel.org/stable/c/10b7ddff50b3334414c0be4b6009671b18ba4845 https://git.kernel.org/stable/c/2ad8af2b70e986284050213230428b823b950a38 https://git.kernel.org/stable/c/bf45c9fe99aa8003d2703f1bd353f956dea47e40 https://git.kernel.org/stable/c/22fa4c8288f1ec40f6d62d7a32c57ac176f9f0bc https://git.kernel.org/stable/c/0a219432127d396120fc88cabd82785e0ff72a2f https://git.kernel.org/stable/c/1775c7ddacfcea29051c67409087578f8 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2021-46999 – sctp: do asoc update earlier in sctp_sf_do_dupcook_a
https://notcve.org/view.php?id=CVE-2021-46999
In the Linux kernel, the following vulnerability has been resolved: sctp: do asoc update earlier in sctp_sf_do_dupcook_a There's a panic that occurs in a few of envs, the call trace is as below: [] general protection fault, ... 0x29acd70f1000a: 0000 [#1] SMP PTI [] RIP: 0010:sctp_ulpevent_notify_peer_addr_change+0x4b/0x1fa [sctp] [] sctp_assoc_control_transport+0x1b9/0x210 [sctp] [] sctp_do_8_2_transport_strike.isra.16+0x15c/0x220 [sctp] [] sctp_cmd_interpreter.isra.21+0x1231/0x1a10 [sctp] [] sctp_do_sm+0xc3/0x2a0 [sctp] [] sctp_generate_timeout_event+0x81/0xf0 [sctp] This is caused by a transport use-after-free issue. When processing a duplicate COOKIE-ECHO chunk in sctp_sf_do_dupcook_a(), both COOKIE-ACK and SHUTDOWN chunks are allocated with the transort from the new asoc. However, later in the sideeffect machine, the old asoc is used to send them out and old asoc's shutdown_last_sent_to is set to the transport that SHUTDOWN chunk attached to in sctp_cmd_setup_t2(), which actually belongs to the new asoc. After the new_asoc is freed and the old asoc T2 timeout, the old asoc's shutdown_last_sent_to that is already freed would be accessed in sctp_sf_t2_timer_expire(). Thanks Alexander and Jere for helping dig into this issue. To fix it, this patch is to do the asoc update first, then allocate the COOKIE-ACK and SHUTDOWN chunks with the 'updated' old asoc. This would make more sense, as a chunk from an asoc shouldn't be sent out with another asoc. We had fixed quite a few issues caused by this. • https://git.kernel.org/stable/c/db8bf823e70f239372c62f13e4eb6f08a1665e8c https://git.kernel.org/stable/c/a204d577be70e0a0a6023cf1b9859c9ebffaeecd https://git.kernel.org/stable/c/145cb2f7177d94bc54563ed26027e952ee0ae03c https://git.kernel.org/stable/c/a5ce8531ea508d270822b2bc6140c6198c8a2a7b https://git.kernel.org/stable/c/d624f2991b977821375fbd56c91b0c91d456a697 https://git.kernel.org/stable/c/b1b31948c0af44628e43353828453461bb74098f https://git.kernel.org/stable/c/f01988ecf3654f805282dce2d3bb9afe68d2691e https://git.kernel.org/stable/c/61b877bad9bb0d82b7d8841be50872557 •