CVSS: 7.1EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47371 – nexthop: Fix memory leaks in nexthop notification chain listeners
https://notcve.org/view.php?id=CVE-2021-47371
In the Linux kernel, the following vulnerability has been resolved: nexthop: Fix memory leaks in nexthop notification chain listeners syzkaller discovered memory leaks [1] that can be reduced to the following commands: # ip nexthop add id 1 blackhole # devlink dev reload pci/0000:06:00.0 As part of the reload flow, mlxsw will unregister its netdevs and then unregister from the nexthop notification chain. Before unregistering from the notification chain, mlxsw will receive delete notifications for nexthop objects using netdevs registered by mlxsw or their uppers. mlxsw will not receive notifications for nexthops using netdevs that are not dismantled as part of the reload flow. For example, the blackhole nexthop above that internally uses the loopback netdev as its nexthop device. One way to fix this problem is to have listeners flush their nexthop tables after unregistering from the notification chain. This is error-prone as evident by this patch and also not symmetric with the registration path where a listener receives a dump of all the existing nexthops. Therefore, fix this problem by replaying delete notifications for the listener being unregistered. This is symmetric to the registration path and also consistent with the netdev notification chain. The above means that unregister_nexthop_notifier(), like register_nexthop_notifier(), will have to take RTNL in order to iterate over the existing nexthops and that any callers of the function cannot hold RTNL. • https://git.kernel.org/stable/c/2a014b200bbd973cc96e082a5bc445fe20b50f32 https://git.kernel.org/stable/c/741760fa6252628a3d3afad439b72437d4b123d9 https://git.kernel.org/stable/c/3106a0847525befe3e22fc723909d1b21eb0d520 • CWE-400: Uncontrolled Resource Consumption •
CVSS: -EPSS: 0%CPEs: 1EXPL: 0CVE-2021-47370 – mptcp: ensure tx skbs always have the MPTCP ext
https://notcve.org/view.php?id=CVE-2021-47370
In the Linux kernel, the following vulnerability has been resolved: mptcp: ensure tx skbs always have the MPTCP ext Due to signed/unsigned comparison, the expression: info->size_goal - skb->len > 0 evaluates to true when the size goal is smaller than the skb size. That results in lack of tx cache refill, so that the skb allocated by the core TCP code lacks the required MPTCP skb extensions. Due to the above, syzbot is able to trigger the following WARN_ON(): WARNING: CPU: 1 PID: 810 at net/mptcp/protocol.c:1366 mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366 Modules linked in: CPU: 1 PID: 810 Comm: syz-executor.4 Not tainted 5.14.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366 Code: ff 4c 8b 74 24 50 48 8b 5c 24 58 e9 0f fb ff ff e8 13 44 8b f8 4c 89 e7 45 31 ed e8 98 57 2e fe e9 81 f4 ff ff e8 fe 43 8b f8 <0f> 0b 41 bd ea ff ff ff e9 6f f4 ff ff 4c 89 e7 e8 b9 8e d2 f8 e9 RSP: 0018:ffffc9000531f6a0 EFLAGS: 00010216 RAX: 000000000000697f RBX: 0000000000000000 RCX: ffffc90012107000 RDX: 0000000000040000 RSI: ffffffff88eac9e2 RDI: 0000000000000003 RBP: ffff888078b15780 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff88eac017 R11: 0000000000000000 R12: ffff88801de0a280 R13: 0000000000006b58 R14: ffff888066278280 R15: ffff88803c2fe9c0 FS: 00007fd9f866e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007faebcb2f718 CR3: 00000000267cb000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __mptcp_push_pending+0x1fb/0x6b0 net/mptcp/protocol.c:1547 mptcp_release_cb+0xfe/0x210 net/mptcp/protocol.c:3003 release_sock+0xb4/0x1b0 net/core/sock.c:3206 sk_stream_wait_memory+0x604/0xed0 net/core/stream.c:145 mptcp_sendmsg+0xc39/0x1bc0 net/mptcp/protocol.c:1749 inet6_sendmsg+0x99/0xe0 net/ipv6/af_inet6.c:643 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:724 sock_write_iter+0x2a0/0x3e0 net/socket.c:1057 call_write_iter include/linux/fs.h:2163 [inline] new_sync_write+0x40b/0x640 fs/read_write.c:507 vfs_write+0x7cf/0xae0 fs/read_write.c:594 ksys_write+0x1ee/0x250 fs/read_write.c:647 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x4665f9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fd9f866e188 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000056c038 RCX: 00000000004665f9 RDX: 00000000000e7b78 RSI: 0000000020000000 RDI: 0000000000000003 RBP: 00000000004bfcc4 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056c038 R13: 0000000000a9fb1f R14: 00007fd9f866e300 R15: 0000000000022000 Fix the issue rewriting the relevant expression to avoid sign-related problems - note: size_goal is always >= 0. Additionally, ensure that the skb in the tx cache always carries the relevant extension. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: asegúrese de que los skbs tx siempre tengan la extensión MPTCP. Debido a la comparación firmado/sin firmar, la expresión: info->size_goal - skb->len > 0 se evalúa como verdadera cuando el tamaño objetivo Es más pequeño que el tamaño skb. Esto da como resultado una falta de recarga de caché de transmisión, de modo que el skb asignado por el código TCP central carece de las extensiones de skb MPTCP requeridas. • https://git.kernel.org/stable/c/e35820fb56415be6924bf552ec223ed5f347b4be https://git.kernel.org/stable/c/f8ff625a8082db8c2b58dcb5229b27928943b94b https://git.kernel.org/stable/c/977d293e23b48a1129830d7968605f61c4af71a0 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47369 – s390/qeth: fix NULL deref in qeth_clear_working_pool_list()
https://notcve.org/view.php?id=CVE-2021-47369
In the Linux kernel, the following vulnerability has been resolved: s390/qeth: fix NULL deref in qeth_clear_working_pool_list() When qeth_set_online() calls qeth_clear_working_pool_list() to roll back after an error exit from qeth_hardsetup_card(), we are at risk of accessing card->qdio.in_q before it was allocated by qeth_alloc_qdio_queues() via qeth_mpc_initialize(). qeth_clear_working_pool_list() then dereferences NULL, and by writing to queue->bufs[i].pool_entry scribbles all over the CPU's lowcore. Resulting in a crash when those lowcore areas are used next (eg. on the next machine-check interrupt). Such a scenario would typically happen when the device is first set online and its queues aren't allocated yet. An early IO error or certain misconfigs (eg. mismatched transport mode, bad portno) then cause us to error out from qeth_hardsetup_card() with card->qdio.in_q still being NULL. Fix it by checking the pointer for NULL before accessing it. Note that we also have (rare) paths inside qeth_mpc_initialize() where a configuration change can cause us to free the existing queues, expecting that subsequent code will allocate them again. If we then error out before that re-allocation happens, the same bug occurs. Root-caused-by: Heiko Carstens <hca@linux.ibm.com> En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/qeth: corrige NULL deref en qeth_clear_working_pool_list(). Cuando qeth_set_online() llama a qeth_clear_working_pool_list() para retroceder después de una salida de error de qeth_hardsetup_card(), corremos el riesgo de acceder a la tarjeta ->qdio.in_q antes de que qeth_alloc_qdio_queues() lo asignara mediante qeth_mpc_initialize(). qeth_clear_working_pool_list() luego elimina la referencia a NULL y, al escribir en queue->bufs[i].pool_entry garabatea por todo el núcleo bajo de la CPU. Lo que resulta en un bloqueo cuando esas áreas de núcleo bajo se usan a continuación (por ejemplo, en la siguiente interrupción de verificación de la máquina). • https://git.kernel.org/stable/c/eff73e16ee116f6eafa2be48fab42659a27cb453 https://git.kernel.org/stable/c/b2400fe7e1011c5f3dc2268e8382082465b1c8a2 https://git.kernel.org/stable/c/22697ca855c06a4a1264d5651542b7d98870a8c4 https://git.kernel.org/stable/c/db94f89e1dadf693c15c2d60de0c34777cea5779 https://git.kernel.org/stable/c/9b00fb12cdc9d8d1c3ffe82a78e74738127803fc https://git.kernel.org/stable/c/248f064af222a1f97ee02c84a98013dfbccad386 • CWE-476: NULL Pointer Dereference •
CVSS: 8.1EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47368 – enetc: Fix illegal access when reading affinity_hint
https://notcve.org/view.php?id=CVE-2021-47368
In the Linux kernel, the following vulnerability has been resolved: enetc: Fix illegal access when reading affinity_hint irq_set_affinity_hit() stores a reference to the cpumask_t parameter in the irq descriptor, and that reference can be accessed later from irq_affinity_hint_proc_show(). Since the cpu_mask parameter passed to irq_set_affinity_hit() has only temporary storage (it's on the stack memory), later accesses to it are illegal. Thus reads from the corresponding procfs affinity_hint file can result in paging request oops. The issue is fixed by the get_cpu_mask() helper, which provides a permanent storage for the cpumask_t parameter. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: enetc: corrige el acceso ilegal al leer affinity_hint irq_set_affinity_hit() almacena una referencia al parámetro cpumask_t en el descriptor irq, y se puede acceder a esa referencia más tarde desde irq_affinity_hint_proc_show(). Dado que el parámetro cpu_mask pasado a irq_set_affinity_hit() solo tiene almacenamiento temporal (está en la memoria de la pila), los accesos posteriores a él son ilegales. • https://git.kernel.org/stable/c/d4fd0404c1c95b17880f254ebfee3485693fa8ba https://git.kernel.org/stable/c/4c4c3052911b577920353a7646e4883d5da40c28 https://git.kernel.org/stable/c/6c3f1b741c6c2914ea120e3a5790d3e900152f7b https://git.kernel.org/stable/c/6f329d9da2a5ae032fcde800a99b118124ed5270 https://git.kernel.org/stable/c/7237a494decfa17d0b9d0076e6cee3235719de90 • CWE-400: Uncontrolled Resource Consumption •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47367 – virtio-net: fix pages leaking when building skb in big mode
https://notcve.org/view.php?id=CVE-2021-47367
In the Linux kernel, the following vulnerability has been resolved: virtio-net: fix pages leaking when building skb in big mode We try to use build_skb() if we had sufficient tailroom. But we forget to release the unused pages chained via private in big mode which will leak pages. Fixing this by release the pages after building the skb in big mode. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio-net: corrige páginas con fugas al compilar skb en modo grande. Intentamos usar build_skb() si tuviéramos suficiente espacio de adaptación. • https://git.kernel.org/stable/c/fb32856b16ad9d5bcd75b76a274e2c515ac7b9d7 https://git.kernel.org/stable/c/f020bb63b5d2e5576acadd10e158fe3b04af67ba https://git.kernel.org/stable/c/afd92d82c9d715fb97565408755acad81573591a • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer •