CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47077 – scsi: qedf: Add pointer checks in qedf_update_link_speed()
https://notcve.org/view.php?id=CVE-2021-47077
In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Add pointer checks in qedf_update_link_speed() The following trace was observed: [ 14.042059] Call Trace: [ 14.042061] <IRQ> [ 14.042068] qedf_link_update+0x144/0x1f0 [qedf] [ 14.042117] qed_link_update+0x5c/0x80 [qed] [ 14.042135] qed_mcp_handle_link_change+0x2d2/0x410 [qed] [ 14.042155] ? qed_set_ptt+0x70/0x80 [qed] [ 14.042170] ? qed_set_ptt+0x70/0x80 [qed] [ 14.042186] ? qed_rd+0x13/0x40 [qed] [ 14.042205] qed_mcp_handle_events+0x437/0x690 [qed] [ 14.042221] ? qed_set_ptt+0x70/0x80 [qed] [ 14.042239] qed_int_sp_dpc+0x3a6/0x3e0 [qed] [ 14.042245] tasklet_action_common.isra.14+0x5a/0x100 [ 14.042250] __do_softirq+0xe4/0x2f8 [ 14.042253] irq_exit+0xf7/0x100 [ 14.042255] do_IRQ+0x7f/0xd0 [ 14.042257] common_interrupt+0xf/0xf [ 14.042259] </IRQ> API qedf_link_update() is getting called from QED but by that time shost_data is not initialised. • https://git.kernel.org/stable/c/61d8658b4a435eac729966cc94cdda077a8df5cd https://git.kernel.org/stable/c/a6362a737572f66051deb7637f3f77ddf7a4402f https://git.kernel.org/stable/c/11014efcec378bb0050a6cf08eaf375e3693400a https://git.kernel.org/stable/c/73578af92a0fae6609b955fcc9113e50e413c80f •
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 •