CVSS: -EPSS: 0%CPEs: 10EXPL: 0CVE-2024-53140 – netlink: terminate outstanding dump on socket close
https://notcve.org/view.php?id=CVE-2024-53140
In the Linux kernel, the following vulnerability has been resolved: netlink: terminate outstanding dump on socket close Netlink supports iterative dumping of data. It provides the families the following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanup The whole process is asynchronous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvmsg() on the socket. This gives the user full control over the dump, but also means that the user can close the socket without getting to the end of the dump. To make sure .start is always paired with .done we check if there is an ongoing dump before freeing the socket, and if so call .done. The complication is that sockets can get freed from BH and .done is allowed to sleep. So we use a workqueue to defer the call, when needed. Unfortunately this does not work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee that we own the last reference, if someone else holds the socket they may release it in BH and we're back to square one. The whole dance, however, appears to be unnecessary. Only the user can interact with dumps, so we can clean up when socket is closed. And close always happens in process context. • https://git.kernel.org/stable/c/ed5d7788a934a4b6d6d025e948ed4da496b4f12e https://git.kernel.org/stable/c/baaf0c65bc8ea9c7a404b09bc8cc3b8a1e4f18df https://git.kernel.org/stable/c/25d9b4bb64ea964769087fc5ae09aee9c838d759 https://git.kernel.org/stable/c/114a61d8d94ae3a43b82446cf737fd757021b834 https://git.kernel.org/stable/c/598c956b62699c3753929602560d8df322e60559 https://git.kernel.org/stable/c/6e3f2c512d2b7dbd247485b1dd9e43e4210a18f4 https://git.kernel.org/stable/c/d2fab3d66cc16cfb9e3ea1772abe6b79b71fa603 https://git.kernel.org/stable/c/4e87a52133284afbd40fb522dbf96e258 •
CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0CVE-2024-53139 – sctp: fix possible UAF in sctp_v6_available()
https://notcve.org/view.php?id=CVE-2024-53139
In the Linux kernel, the following vulnerability has been resolved: sctp: fix possible UAF in sctp_v6_available() A lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints that sctp_v6_available() is calling dev_get_by_index_rcu() and ipv6_chk_addr() without holding rcu. [1] ============================= WARNING: suspicious RCU usage 6.12.0-rc5-virtme #1216 Tainted: G W ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by sctp_hello/31495: #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp stack backtrace: CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G W 6.12.0-rc5-virtme #1216 Tainted: [W]=WARN Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7)) sctp_v6_available (net/sctp/ipv6.c:701) sctp sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp sctp_bind (net/sctp/socket.c:320) sctp inet6_bind_sk (net/ipv6/af_inet6.c:465) ? security_socket_bind (security/security.c:4581 (discriminator 1)) __sys_bind (net/socket.c:1848 net/socket.c:1869) ? do_user_addr_fault (. • https://git.kernel.org/stable/c/6fe1e52490a91cb23f6b3aafc93e7c5beb99f862 https://git.kernel.org/stable/c/ad975697211f4f2c4ce61c3ba524fd14d88ceab8 https://git.kernel.org/stable/c/05656a66592759242c74063616291b7274d11b2f https://git.kernel.org/stable/c/eb72e7fcc83987d5d5595b43222f23b295d5de7f • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-53138 – net/mlx5e: kTLS, Fix incorrect page refcounting
https://notcve.org/view.php?id=CVE-2024-53138
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: kTLS, Fix incorrect page refcounting The kTLS tx handling code is using a mix of get_page() and page_ref_inc() APIs to increment the page reference. But on the release path (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used. This is an issue when using pages from large folios: the get_page() references are stored on the folio page while the page_ref_inc() references are stored directly in the given page. On release the folio page will be dereferenced too many times. This was found while doing kTLS testing with sendfile() + ZC when the served file was read from NFS on a kernel with NFS large folios support (commit 49b29a573da8 ("nfs: add support for large folios")). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: kTLS, Fix wrong page refcounting El código de manejo de tx de kTLS usa una combinación de API get_page() y page_ref_inc() para incrementar la referencia de página. Pero en la ruta de lanzamiento (mlx5e_ktls_tx_handle_resync_dump_comp()), solo se usa put_page(). • https://git.kernel.org/stable/c/84d1bb2b139e0184b1754aa1b5776186b475fce8 https://git.kernel.org/stable/c/a0ddb20a748b122ea86003485f7992fa5e84cc95 https://git.kernel.org/stable/c/ffad2ac8c859c1c1a981fe9c4f7ff925db684a43 https://git.kernel.org/stable/c/c7b97f9e794d8e2bbaa50e1d6c230196fd214b5e https://git.kernel.org/stable/c/69fbd07f17b0fdaf8970bc705f5bf115c297839d https://git.kernel.org/stable/c/93a14620b97c911489a5b008782f3d9b0c4aeff4 https://git.kernel.org/stable/c/2723e8b2cbd486cb96e5a61b22473f7fd62e18df https://git.kernel.org/stable/c/dd6e972cc5890d91d6749bb48e3912721 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-53137 – ARM: fix cacheflush with PAN
https://notcve.org/view.php?id=CVE-2024-53137
In the Linux kernel, the following vulnerability has been resolved: ARM: fix cacheflush with PAN It seems that the cacheflush syscall got broken when PAN for LPAE was implemented. User access was not enabled around the cache maintenance instructions, causing them to fault. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: reparar cacheflush con PAN Parece que la llamada al sistema cacheflush se rompió cuando se implementó PAN para LPAE. El acceso de usuario no estaba habilitado en torno a las instrucciones de mantenimiento de caché, lo que provocó que fallaran. • https://git.kernel.org/stable/c/7af5b901e84743c608aae90cb0e429702812c324 https://git.kernel.org/stable/c/e6960a2ed49c9a25357817535f7cc50594a58604 https://git.kernel.org/stable/c/ca29cfcc4a21083d671522ad384532e28a43f033 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-53136 – mm: revert "mm: shmem: fix data-race in shmem_getattr()"
https://notcve.org/view.php?id=CVE-2024-53136
In the Linux kernel, the following vulnerability has been resolved: mm: revert "mm: shmem: fix data-race in shmem_getattr()" Revert d949d1d14fa2 ("mm: shmem: fix data-race in shmem_getattr()") as suggested by Chuck [1]. It is causing deadlocks when accessing tmpfs over NFS. As Hugh commented, "added just to silence a syzbot sanitizer splat: added where there has never been any practical problem". En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: revert "mm: shmem: fix data-race in shmem_getattr()" Revert d949d1d14fa2 ("mm: shmem: fix data-race in shmem_getattr()") como lo sugirió Chuck [1]. Está causando bloqueos al acceder a tmpfs a través de NFS. Como comentó Hugh, "agregado solo para silenciar un splat de sanitizador de syzbot: agregado donde nunca ha habido ningún problema práctico". • https://git.kernel.org/stable/c/9fb9703cd43ee20a6de8ccdef991677b7274cec0 https://git.kernel.org/stable/c/7cc30ada84323be19395094d567579536e0d187e https://git.kernel.org/stable/c/bda1a99a0dd644f31a87d636ac624eeb975cb65a https://git.kernel.org/stable/c/3d9528484480e8f4979b3a347930ed383be99f89 https://git.kernel.org/stable/c/82cae1e30bd940253593c2d4f16d88343d1358f4 https://git.kernel.org/stable/c/edd1f905050686fdc4cfe233d818469fdf7d5ff8 https://git.kernel.org/stable/c/ffd56612566bc23877c8f45def2801f3324a222a https://git.kernel.org/stable/c/36b537e8f302f670c7cf35d88a3a29444 •