CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-53121 – net/mlx5: fs, lock FTE when checking if active
https://notcve.org/view.php?id=CVE-2024-53121
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: fs, lock FTE when checking if active The referenced commits introduced a two-step process for deleting FTEs: - Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE. - Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray. However, this approach encounters a race condition if a rule with the same match value is added simultaneously. In this scenario, fs_core may set the hardware deletion function to NULL prematurely, causing a panic during subsequent rule deletions. To prevent this, ensure the active flag of the FTE is checked under a lock, which will prevent the fs_core layer from attaching a new steering rule to an FTE that is in the process of deletion. [ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func [ 438.968205] ------------[ cut here ]------------ [ 438.968654] refcount_t: decrement hit 0; leaking memory. [ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110 [ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower] [ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8 [ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110 [ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90 [ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286 [ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000 [ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0 [ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0 [ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0 [ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0 [ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000 [ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0 [ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 438.986507] Call Trace: [ 438.986799] <TASK> [ 438.987070] ? __warn+0x7d/0x110 [ 438.987426] ? refcount_warn_saturate+0xfb/0x110 [ 438.987877] ? report_bug+0x17d/0x190 [ 438.988261] ? • https://git.kernel.org/stable/c/718ce4d601dbf73b5dbe024a88c9e34168fe87f2 https://git.kernel.org/stable/c/0d568258f99f2076ab02e9234cbabbd43e12f30e https://git.kernel.org/stable/c/a508c74ceae2f5a4647f67c362126516d6404ed9 https://git.kernel.org/stable/c/5b47c2f47c2fe921681f4a4fe2790375e6c04cdd https://git.kernel.org/stable/c/bfba288f53192db08c68d4c568db9783fb9cb838 https://git.kernel.org/stable/c/094d1a2121cee1e85ab07d74388f94809dcfb5b9 https://git.kernel.org/stable/c/933ef0d17f012b653e9e6006e3f50c8d0238b5ed https://git.kernel.org/stable/c/9ca314419930f9135727e39d77e66262d •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-53120 – net/mlx5e: CT: Fix null-ptr-deref in add rule err flow
https://notcve.org/view.php?id=CVE-2024-53120
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT: Fix null-ptr-deref in add rule err flow In error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add() callback returns error, zone_rule->attr is used uninitiated. Fix it to use attr which has the needed pointer value. Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] … Call Trace: <TASK> ? __die+0x20/0x70 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x140 ? • https://git.kernel.org/stable/c/7fac5c2eced36f335ee19ff316bd3182fbeda823 https://git.kernel.org/stable/c/882f392d9e3649557e71efd78ae20c86039ffb7c https://git.kernel.org/stable/c/0c7c70ff8b696cfedba350411dca736361ef9a0f https://git.kernel.org/stable/c/06dc488a593020bd2f006798557d2a32104d8359 https://git.kernel.org/stable/c/6030f8bd7902e9e276a0edc09bf11979e4e2bc2e https://git.kernel.org/stable/c/e99c6873229fe0482e7ceb7d5600e32d623ed9d9 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-53119 – virtio/vsock: Fix accept_queue memory leak
https://notcve.org/view.php?id=CVE-2024-53119
In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Fix accept_queue memory leak As the final stages of socket destruction may be delayed, it is possible that virtio_transport_recv_listen() will be called after the accept_queue has been flushed, but before the SOCK_DONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak. vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK (!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) release close_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound release Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during socket destruction. unreferenced object 0xffff888109e3f800 (size 2040): comm "kworker/5:2", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [<ffffffff81418ff1>] kmem_cache_alloc_noprof+0x2c1/0x360 [<ffffffff81d27aa0>] sk_prot_alloc+0x30/0x120 [<ffffffff81d2b54c>] sk_alloc+0x2c/0x4b0 [<ffffffff81fe049a>] __vsock_create.constprop.0+0x2a/0x310 [<ffffffff81fe6d6c>] virtio_transport_recv_pkt+0x4dc/0x9a0 [<ffffffff81fe745d>] vsock_loopback_work+0xfd/0x140 [<ffffffff810fc6ac>] process_one_work+0x20c/0x570 [<ffffffff810fce3f>] worker_thread+0x1bf/0x3a0 [<ffffffff811070dd>] kthread+0xdd/0x110 [<ffffffff81044fdd>] ret_from_fork+0x2d/0x50 [<ffffffff8100785a>] ret_from_fork_asm+0x1a/0x30 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio/vsock: Se soluciona la pérdida de memoria de accept_queue. Como las etapas finales de la destrucción del socket pueden demorarse, es posible que se llame a virtio_transport_recv_listen() después de que se haya vaciado accept_queue, pero antes de que se haya establecido el indicador SOCK_DONE. • https://git.kernel.org/stable/c/3fe356d58efae54dade9ec94ea7c919ed20cf4db https://git.kernel.org/stable/c/2e7dd95046203bd05e8f4dc06ee53cace70a8e3c https://git.kernel.org/stable/c/e26fa236758e8baa61a82cfd9fd4388d2e8d6a4c https://git.kernel.org/stable/c/4310902c766e371359e6c6311056ae80b5beeac9 https://git.kernel.org/stable/c/946c7600fa2207cc8d3fbc86a518ec56f98a5813 https://git.kernel.org/stable/c/897617a413e0bf1c6380e3b34b2f28f450508549 https://git.kernel.org/stable/c/2415345042245de7601dcc6eafdbe3a3dcc9e379 https://git.kernel.org/stable/c/d7b0ff5a866724c3ad21f2628c22a6333 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-53114 – x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client
https://notcve.org/view.php?id=CVE-2024-53114
In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client A number of Zen4 client SoCs advertise the ability to use virtualized VMLOAD/VMSAVE, but using these instructions is reported to be a cause of a random host reboot. These instructions aren't intended to be advertised on Zen4 client so clear the capability. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/CPU/AMD: Borrar VMLOAD/VMSAVE virtualizado en el cliente Zen4 Varios SoC de cliente Zen4 anuncian la capacidad de usar VMLOAD/VMSAVE virtualizado, pero se informa que el uso de estas instrucciones es la causa de un reinicio aleatorio del host. Estas instrucciones no están destinadas a ser anunciadas en el cliente Zen4, por lo que se debe borrar la capacidad. • https://git.kernel.org/stable/c/00c713f84f477a85e524f34aad8fbd11a1c051f0 https://git.kernel.org/stable/c/a5ca1dc46a6b610dd4627d8b633d6c84f9724ef0 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-53113 – mm: fix NULL pointer dereference in alloc_pages_bulk_noprof
https://notcve.org/view.php?id=CVE-2024-53113
In the Linux kernel, the following vulnerability has been resolved: mm: fix NULL pointer dereference in alloc_pages_bulk_noprof We triggered a NULL pointer dereference for ac.preferred_zoneref->zone in alloc_pages_bulk_noprof() when the task is migrated between cpusets. When cpuset is enabled, in prepare_alloc_pages(), ac->nodemask may be ¤t->mems_allowed. when first_zones_zonelist() is called to find preferred_zoneref, the ac->nodemask may be modified concurrently if the task is migrated between different cpusets. Assuming we have 2 NUMA Node, when traversing Node1 in ac->zonelist, the nodemask is 2, and when traversing Node2 in ac->zonelist, the nodemask is 1. As a result, the ac->preferred_zoneref points to NULL zone. In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds a allowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leading to NULL pointer dereference. __alloc_pages_noprof() fixes this issue by checking NULL pointer in commit ea57485af8f4 ("mm, page_alloc: fix check for NULL preferred_zone") and commit df76cee6bbeb ("mm, page_alloc: remove redundant checks from alloc fastpath"). To fix it, check NULL pointer for preferred_zoneref->zone. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: corregir la desreferencia de puntero NULL en alloc_pages_bulk_noprof Activamos una desreferencia de puntero NULL para ac.preferred_zoneref->zone en alloc_pages_bulk_noprof() cuando la tarea se migra entre conjuntos de CPU. • https://git.kernel.org/stable/c/387ba26fb1cb9be9e35dc14a6d97188e916eda05 https://git.kernel.org/stable/c/903d896448c2e50e8652aaba529a30d4d1eaa0e5 https://git.kernel.org/stable/c/6addb2d9501ec866d7b3a3b4e665307c437e9be2 https://git.kernel.org/stable/c/d0f16cec79774c3132df006cf771eddd89d08f58 https://git.kernel.org/stable/c/31502374627ba9ec3e710dbd0bb00457cc6d2c19 https://git.kernel.org/stable/c/8ce41b0f9d77cca074df25afd39b86e2ee3aa68e •