CVSS: 3.8EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52584 – spmi: mediatek: Fix UAF on device remove
https://notcve.org/view.php?id=CVE-2023-52584
In the Linux kernel, the following vulnerability has been resolved: spmi: mediatek: Fix UAF on device remove The pmif driver data that contains the clocks is allocated along with spmi_controller. On device remove, spmi_controller will be freed first, and then devres , including the clocks, will be cleanup. This leads to UAF because putting the clocks will access the clocks in the pmif driver data, which is already freed along with spmi_controller. This can be reproduced by enabling DEBUG_TEST_DRIVER_REMOVE and building the kernel with KASAN. Fix the UAF issue by using unmanaged clk_bulk_get() and putting the clocks before freeing spmi_controller. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: spmi: mediatek: reparar UAF en la eliminación del dispositivo. Los datos del controlador pmif que contienen los relojes se asignan junto con spmi_controller. Al eliminar el dispositivo, primero se liberará spmi_controller y luego se limpiarán los devres, incluidos los relojes. Esto lleva a UAF porque al poner los relojes se accederá a los relojes en los datos del controlador pmif, que ya están liberados junto con spmi_controller. • https://git.kernel.org/stable/c/521f28eedd6b14228c46e3b81e3bf9b90c2818d8 https://git.kernel.org/stable/c/f8dcafcb54632536684336161da8bdd52120f95e https://git.kernel.org/stable/c/9a3881b1f07db1bb55cb0108e6f05cfd027eaf2e https://git.kernel.org/stable/c/e821d50ab5b956ed0effa49faaf29912fd4106d9 • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52583 – ceph: fix deadlock or deadcode of misusing dget()
https://notcve.org/view.php?id=CVE-2023-52583
In the Linux kernel, the following vulnerability has been resolved: ceph: fix deadlock or deadcode of misusing dget() The lock order is incorrect between denty and its parent, we should always make sure that the parent get the lock first. But since this deadcode is never used and the parent dir will always be set from the callers, let's just remove it. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ceph: corrige el punto muerto o el código muerto por uso incorrecto de dget() El orden de bloqueo es incorrecto entre denty y su padre, siempre debemos asegurarnos de que el padre obtenga el bloqueo primero. Pero dado que este código muerto nunca se usa y el directorio principal siempre será configurado por quienes llaman, simplemente eliminémoslo. • https://git.kernel.org/stable/c/eb55ba8aa7fb7aad54f40fbf4d8dcdfdba0bebf6 https://git.kernel.org/stable/c/6ab4fd508fad942f1f1ba940492f2735e078e980 https://git.kernel.org/stable/c/e016e358461b89b231626fcf78c5c38e35c44fd3 https://git.kernel.org/stable/c/a9c15d6e8aee074fae66c04d114f20b84274fcca https://git.kernel.org/stable/c/7f2649c94264d00df6b6ac27161e9f4372a3450e https://git.kernel.org/stable/c/196b87e5c00ce021e164a5de0f0d04f4116a9160 https://git.kernel.org/stable/c/76cb2aa3421fee4fde706dec41b1344bc0a9ad67 https://git.kernel.org/stable/c/b493ad718b1f0357394d2cdecbf00a44a •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26622 – tomoyo: fix UAF write bug in tomoyo_write_control()
https://notcve.org/view.php?id=CVE-2024-26622
In the Linux kernel, the following vulnerability has been resolved: tomoyo: fix UAF write bug in tomoyo_write_control() Since tomoyo_write_control() updates head->write_buf when write() of long lines is requested, we need to fetch head->write_buf after head->io_sem is held. Otherwise, concurrent write() requests can cause use-after-free-write and double-free problems. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tomoyo: corrige el error de escritura UAF en tomoyo_write_control() Dado que tomoyo_write_control() actualiza head->write_buf cuando se solicita write() de líneas largas, necesitamos recuperar head->write_buf después head->io_sem se mantiene. De lo contrario, las solicitudes de escritura () simultáneas pueden causar problemas de use-after-free-write y de doble liberación. • https://git.kernel.org/stable/c/bd03a3e4c9a9df0c6b007045fa7fc8889111a478 https://git.kernel.org/stable/c/a23ac1788e2c828c097119e9a3178f0b7e503fee https://git.kernel.org/stable/c/7d930a4da17958f869ef679ee0e4a8729337affc https://git.kernel.org/stable/c/3bfe04c1273d30b866f4c7c238331ed3b08e5824 https://git.kernel.org/stable/c/2caa605079488da9601099fbda460cfc1702839f https://git.kernel.org/stable/c/6edefe1b6c29a9932f558a898968a9fcbeec5711 https://git.kernel.org/stable/c/2f03fc340cac9ea1dc63cbf8c93dd2eb0f227815 https://lists.debian.org/debian-lts-announce/2024/06/ •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52582 – netfs: Only call folio_start_fscache() one time for each folio
https://notcve.org/view.php?id=CVE-2023-52582
In the Linux kernel, the following vulnerability has been resolved: netfs: Only call folio_start_fscache() one time for each folio If a network filesystem using netfs implements a clamp_length() function, it can set subrequest lengths smaller than a page size. When we loop through the folios in netfs_rreq_unlock_folios() to set any folios to be written back, we need to make sure we only call folio_start_fscache() once for each folio. Otherwise, this simple testcase: mount -o fsc,rsize=1024,wsize=1024 127.0.0.1:/export /mnt/nfs dd if=/dev/zero of=/mnt/nfs/file.bin bs=4096 count=1 1+0 records in 1+0 records out 4096 bytes (4.1 kB, 4.0 KiB) copied, 0.0126359 s, 324 kB/s echo 3 > /proc/sys/vm/drop_caches cat /mnt/nfs/file.bin > /dev/null will trigger an oops similar to the following: page dumped because: VM_BUG_ON_FOLIO(folio_test_private_2(folio)) ------------[ cut here ]------------ kernel BUG at include/linux/netfs.h:44! ... CPU: 5 PID: 134 Comm: kworker/u16:5 Kdump: loaded Not tainted 6.4.0-rc5 ... RIP: 0010:netfs_rreq_unlock_folios+0x68e/0x730 [netfs] ... Call Trace: netfs_rreq_assess+0x497/0x660 [netfs] netfs_subreq_terminated+0x32b/0x610 [netfs] nfs_netfs_read_completion+0x14e/0x1a0 [nfs] nfs_read_completion+0x2f9/0x330 [nfs] rpc_free_task+0x72/0xa0 [sunrpc] rpc_async_release+0x46/0x70 [sunrpc] process_one_work+0x3bd/0x710 worker_thread+0x89/0x610 kthread+0x181/0x1c0 ret_from_fork+0x29/0x50 • https://git.kernel.org/stable/c/3d3c95046742e4eebaa4b891b0b01cbbed94ebbd https://git.kernel.org/stable/c/df9950d37df113db59495fa09d060754366a2b7c https://git.kernel.org/stable/c/d9f5537479d4ec97ea92ff24e81a517d5772581a https://git.kernel.org/stable/c/df1c357f25d808e30b216188330e708e09e1a412 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52580 – net/core: Fix ETH_P_1588 flow dissector
https://notcve.org/view.php?id=CVE-2023-52580
In the Linux kernel, the following vulnerability has been resolved: net/core: Fix ETH_P_1588 flow dissector When a PTP ethernet raw frame with a size of more than 256 bytes followed by a 0xff pattern is sent to __skb_flow_dissect, nhoff value calculation is wrong. For example: hdr->message_length takes the wrong value (0xffff) and it does not replicate real header length. In this case, 'nhoff' value was overridden and the PTP header was badly dissected. This leads to a kernel crash. net/core: flow_dissector net/core flow dissector nhoff = 0x0000000e net/core flow dissector hdr->message_length = 0x0000ffff net/core flow dissector nhoff = 0x0001000d (u16 overflow) ... skb linear: 00000000: 00 a0 c9 00 00 00 00 a0 c9 00 00 00 88 skb frag: 00000000: f7 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Using the size of the ptp_header struct will allow the corrected calculation of the nhoff value. net/core flow dissector nhoff = 0x0000000e net/core flow dissector nhoff = 0x00000030 (sizeof ptp_header) ... skb linear: 00000000: 00 a0 c9 00 00 00 00 a0 c9 00 00 00 88 f7 ff ff skb linear: 00000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff skb linear: 00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff skb frag: 00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Kernel trace: [ 74.984279] ------------[ cut here ]------------ [ 74.989471] kernel BUG at include/linux/skbuff.h:2440! [ 74.995237] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 75.001098] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G U 5.15.85-intel-ese-standard-lts #1 [ 75.011629] Hardware name: Intel Corporation A-Island (CPU:AlderLake)/A-Island (ID:06), BIOS SB_ADLP.01.01.00.01.03.008.D-6A9D9E73-dirty Mar 30 2023 [ 75.026507] RIP: 0010:eth_type_trans+0xd0/0x130 [ 75.031594] Code: 03 88 47 78 eb c7 8b 47 68 2b 47 6c 48 8b 97 c0 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb ab <0f> 0b b8 00 01 00 00 eb a2 48 85 ff 74 eb 48 8d 54 24 06 31 f6 b9 [ 75.052612] RSP: 0018:ffff9948c0228de0 EFLAGS: 00010297 [ 75.058473] RAX: 00000000000003f2 RBX: ffff8e47047dc300 RCX: 0000000000001003 [ 75.066462] RDX: ffff8e4e8c9ea040 RSI: ffff8e4704e0a000 RDI: ffff8e47047dc300 [ 75.074458] RBP: ffff8e4704e2acc0 R08: 00000000000003f3 R09: 0000000000000800 [ 75.082466] R10: 000000000000000d R11: ffff9948c0228dec R12: ffff8e4715e4e010 [ 75.090461] R13: ffff9948c0545018 R14: 0000000000000001 R15: 0000000000000800 [ 75.098464] FS: 0000000000000000(0000) GS:ffff8e4e8fb00000(0000) knlGS:0000000000000000 [ 75.107530] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 75.113982] CR2: 00007f5eb35934a0 CR3: 0000000150e0a002 CR4: 0000000000770ee0 [ 75.121980] PKRU: 55555554 [ 75.125035] Call Trace: [ 75.127792] <IRQ> [ 75.130063] ? • https://git.kernel.org/stable/c/4f1cc51f34886d645cd3e8fc2915cc9b7a55c3b6 https://git.kernel.org/stable/c/f90a7b9586d72f907092078a9f394733ca502cc9 https://git.kernel.org/stable/c/488ea2a3e2666022f79abfdd7d12e8305fc27a40 https://git.kernel.org/stable/c/48e105a2a1a10adc21c0ae717969f5e8e990ba48 https://git.kernel.org/stable/c/75ad80ed88a182ab2ad5513e448cf07b403af5c3 https://access.redhat.com/security/cve/CVE-2023-52580 https://bugzilla.redhat.com/show_bug.cgi?id=2267760 • CWE-131: Incorrect Calculation of Buffer Size •