CVSS: 4.4EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47076 – RDMA/rxe: Return CQE error if invalid lkey was supplied
https://notcve.org/view.php?id=CVE-2021-47076
In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Return CQE error if invalid lkey was supplied RXE is missing update of WQE status in LOCAL_WRITE failures. This caused the following kernel panic if someone sent an atomic operation with an explicitly wrong lkey. [leonro@vm ~]$ mkt test test_atomic_invalid_lkey (tests.test_atomic.AtomicTest) ... WARNING: CPU: 5 PID: 263 at drivers/infiniband/sw/rxe/rxe_comp.c:740 rxe_completer+0x1a6d/0x2e30 [rdma_rxe] Modules linked in: crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel rdma_ucm rdma_cm ib_umad ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core mlx5_core ptp pps_core CPU: 5 PID: 263 Comm: python3 Not tainted 5.13.0-rc1+ #2936 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:rxe_completer+0x1a6d/0x2e30 [rdma_rxe] Code: 03 0f 8e 65 0e 00 00 3b 93 10 06 00 00 0f 84 82 0a 00 00 4c 89 ff 4c 89 44 24 38 e8 2d 74 a9 e1 4c 8b 44 24 38 e9 1c f5 ff ff <0f> 0b e9 0c e8 ff ff b8 05 00 00 00 41 bf 05 00 00 00 e9 ab e7 ff RSP: 0018:ffff8880158af090 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888016a78000 RCX: ffffffffa0cf1652 RDX: 1ffff9200004b442 RSI: 0000000000000004 RDI: ffffc9000025a210 RBP: dffffc0000000000 R08: 00000000ffffffea R09: ffff88801617740b R10: ffffed1002c2ee81 R11: 0000000000000007 R12: ffff88800f3b63e8 R13: ffff888016a78008 R14: ffffc9000025a180 R15: 000000000000000c FS: 00007f88b622a740(0000) GS:ffff88806d540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f88b5a1fa10 CR3: 000000000d848004 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: rxe_do_task+0x130/0x230 [rdma_rxe] rxe_rcv+0xb11/0x1df0 [rdma_rxe] rxe_loopback+0x157/0x1e0 [rdma_rxe] rxe_responder+0x5532/0x7620 [rdma_rxe] rxe_do_task+0x130/0x230 [rdma_rxe] rxe_rcv+0x9c8/0x1df0 [rdma_rxe] rxe_loopback+0x157/0x1e0 [rdma_rxe] rxe_requester+0x1efd/0x58c0 [rdma_rxe] rxe_do_task+0x130/0x230 [rdma_rxe] rxe_post_send+0x998/0x1860 [rdma_rxe] ib_uverbs_post_send+0xd5f/0x1220 [ib_uverbs] ib_uverbs_write+0x847/0xc80 [ib_uverbs] vfs_write+0x1c5/0x840 ksys_write+0x176/0x1d0 do_syscall_64+0x3f/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae • https://git.kernel.org/stable/c/8700e3e7c4857d28ebaa824509934556da0b3e76 https://git.kernel.org/stable/c/abe31d25facdb9109fe2cf69890748295291570c https://git.kernel.org/stable/c/dc07628bd2bbc1da768e265192c28ebd301f509d https://access.redhat.com/security/cve/CVE-2021-47076 https://bugzilla.redhat.com/show_bug.cgi?id=2267525 • CWE-20: Improper Input Validation •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47074 – nvme-loop: fix memory leak in nvme_loop_create_ctrl()
https://notcve.org/view.php?id=CVE-2021-47074
In the Linux kernel, the following vulnerability has been resolved: nvme-loop: fix memory leak in nvme_loop_create_ctrl() When creating loop ctrl in nvme_loop_create_ctrl(), if nvme_init_ctrl() fails, the loop ctrl should be freed before jumping to the "out" label. • https://git.kernel.org/stable/c/3a85a5de29ea779634ddfd768059e06196687aba https://git.kernel.org/stable/c/9c980795ccd77e8abec33dd6fe28dfe1c4083e65 https://git.kernel.org/stable/c/551ba08d4b7eb26f75758cdb9f15105b276517ad https://git.kernel.org/stable/c/03504e3b54cc8118cc26c064e60a0b00c2308708 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2021-47068 – net/nfc: fix use-after-free llcp_sock_bind/connect
https://notcve.org/view.php?id=CVE-2021-47068
In the Linux kernel, the following vulnerability has been resolved: net/nfc: fix use-after-free llcp_sock_bind/connect Commits 8a4cd82d ("nfc: fix refcount leak in llcp_sock_connect()") and c33b1cc62 ("nfc: fix refcount leak in llcp_sock_bind()") fixed a refcount leak bug in bind/connect but introduced a use-after-free if the same local is assigned to 2 different sockets. This can be triggered by the following simple program: int sock1 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); int sock2 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); memset( &addr, 0, sizeof(struct sockaddr_nfc_llcp) ); addr.sa_family = AF_NFC; addr.nfc_protocol = NFC_PROTO_NFC_DEP; bind( sock1, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) ) bind( sock2, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) ) close(sock1); close(sock2); Fix this by assigning NULL to llcp_sock->local after calling nfc_llcp_local_put. This addresses CVE-2021-23134. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/nfc: corrige use-after-free llcp_sock_bind/connect Commits 8a4cd82d ("nfc: corrige la fuga de refcount en llcp_sock_connect()") y c33b1cc62 ("nfc: corrige la fuga de refcount en llcp_sock_bind()") corrigió un error de fuga de recuento en bind/connect pero introdujo un Use-After-Free si el mismo local está asignado a 2 sockets diferentes. Esto puede activarse mediante el siguiente programa simple: int sock1 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); int sock2 = conector (AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP); memset( &addr, 0, sizeof(struct sockaddr_nfc_llcp) ); addr.sa_family = AF_NFC; addr.nfc_protocol = NFC_PROTO_NFC_DEP; bind( sock1, (struct sockaddr*) & addr, sizeof(struct sockaddr_nfc_llcp) ) bind( sock2, (struct sockaddr*) & addr, sizeof(struct sockaddr_nfc_llcp) ) close(sock1); cerrar(calcetín2); Solucione este problema asignando NULL a llcp_sock->local después de llamar a nfc_llcp_local_put. Esto aborda CVE-2021-23134. • https://git.kernel.org/stable/c/a1cdd18c49d23ec38097ac2c5b0d761146fc0109 https://git.kernel.org/stable/c/18013007b596771bf5f5e7feee9586fb0386ad14 https://git.kernel.org/stable/c/538a6ff11516d38a61e237d2d2dc04c30c845fbe https://git.kernel.org/stable/c/adbb1d218c5f56dbae052765da83c0f57fce2a31 https://git.kernel.org/stable/c/c89903c9eff219a4695e63715cf922748d743f65 https://git.kernel.org/stable/c/6fb003e5ae18d8cda4c8a1175d9dd8db12bec049 https://git.kernel.org/stable/c/8c9e4971e142e2899606a2490b77a1208c1f4638 https://git.kernel.org/stable/c/c33b1cc62ac05c1dbb1cdafe2eb66da01 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47063 – drm: bridge/panel: Cleanup connector on bridge detach
https://notcve.org/view.php?id=CVE-2021-47063
In the Linux kernel, the following vulnerability has been resolved: drm: bridge/panel: Cleanup connector on bridge detach If we don't call drm_connector_cleanup() manually in panel_bridge_detach(), the connector will be cleaned up with the other DRM objects in the call to drm_mode_config_cleanup(). However, since our drm_connector is devm-allocated, by the time drm_mode_config_cleanup() will be called, our connector will be long gone. Therefore, the connector must be cleaned up when the bridge is detached to avoid use-after-free conditions. v2: Cleanup connector only if it was created v3: Add FIXME v4: (Use connector->dev) directly in if() block En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm: bridge/panel: Limpiar conector en bridge detach Si no llamamos a drm_connector_cleanup() manualmente en panel_bridge_detach(), el conector se limpiará con los demás objetos DRM en la llamada a drm_mode_config_cleanup(). Sin embargo, dado que nuestro drm_connector está asignado por devm, para cuando se llame a drm_mode_config_cleanup(), nuestro conector ya no existirá. Por lo tanto, el conector debe limpiarse cuando se retira el puente para evitar condiciones de uso después de su liberación. v2: Limpiar el conector solo si fue creado v3: Agregar FIXME v4: (Usar conector->dev) directamente en el bloque if() • https://git.kernel.org/stable/c/13dfc0540a575b47b2d640b093ac16e9e09474f6 https://git.kernel.org/stable/c/ce450934a00cf896e648fde08d0bd1426653d7a2 https://git.kernel.org/stable/c/18149b420c9bd93c443e8d1f48a063d71d9f6aa1 https://git.kernel.org/stable/c/98d7d76a74e48ec3ddf2e23950adff7edcab9327 https://git.kernel.org/stable/c/4d906839d321c2efbf3fed4bc31ffd9ff55b75c0 •
CVSS: -EPSS: 0%CPEs: 10EXPL: 0CVE-2021-47061 – KVM: Destroy I/O bus devices on unregister failure _after_ sync'ing SRCU
https://notcve.org/view.php?id=CVE-2021-47061
In the Linux kernel, the following vulnerability has been resolved: KVM: Destroy I/O bus devices on unregister failure _after_ sync'ing SRCU If allocating a new instance of an I/O bus fails when unregistering a device, wait to destroy the device until after all readers are guaranteed to see the new null bus. Destroying devices before the bus is nullified could lead to use-after-free since readers expect the devices on their reference of the bus to remain valid. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: Destruye los dispositivos del bus de E/S al cancelar el registro _después_ de sincronizar SRCU Si falla la asignación de una nueva instancia de un bus de E/S al cancelar el registro de un dispositivo, espere para destruir el dispositivo hasta que todos los lectores tengan la garantía de ver el nuevo bus nulo. Destruir dispositivos antes de que se anule el bus podría dar lugar a un uso posterior a la liberación, ya que los lectores esperan que los dispositivos en su referencia del bus sigan siendo válidos. • https://git.kernel.org/stable/c/f65886606c2d3b562716de030706dfe1bea4ed5e https://git.kernel.org/stable/c/f0dfffce3f4ffd5f822568a4a6fb34c010e939d1 https://git.kernel.org/stable/c/840e124f89a5127e7eb97ebf377f4b8ca745c070 https://git.kernel.org/stable/c/40a023f681befd9b2862a3c16fb306a38b359ae5 https://git.kernel.org/stable/c/19184bd06f488af62924ff1747614a8cb284ad63 https://git.kernel.org/stable/c/41b2ea7a6a11e2b1a7f2c29e1675a709a6b2b98d https://git.kernel.org/stable/c/68c125324b5e1d1d22805653735442923d896a1d https://git.kernel.org/stable/c/03c6cccedd3913006744faa252a4da514 •