CVSS: 6.9EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52584 – spmi: mediatek: Fix UAF on device remove
https://notcve.org/view.php?id=CVE-2023-52584
06 Mar 2024 — 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 ... • https://git.kernel.org/stable/c/521f28eedd6b14228c46e3b81e3bf9b90c2818d8 • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52583 – ceph: fix deadlock or deadcode of misusing dget()
https://notcve.org/view.php?id=CVE-2023-52583
06 Mar 2024 — 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 blo... • https://git.kernel.org/stable/c/eb55ba8aa7fb7aad54f40fbf4d8dcdfdba0bebf6 •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2022-48630 – crypto: qcom-rng - fix infinite loop on requests not multiple of WORD_SZ
https://notcve.org/view.php?id=CVE-2022-48630
05 Mar 2024 — In the Linux kernel, the following vulnerability has been resolved: crypto: qcom-rng - fix infinite loop on requests not multiple of WORD_SZ The commit referenced in the Fixes tag removed the 'break' from the else branch in qcom_rng_read(), causing an infinite loop whenever 'max' is not a multiple of WORD_SZ. This can be reproduced e.g. by running: kcapi-rng -b 67 >/dev/null There are many ways to fix this without adding back the 'break', but they all seem more awkward than simply adding it back, so do just... • https://git.kernel.org/stable/c/a8e32bbb96c25b7ab29b1894dcd45e0b3b08fd9d •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2022-48629 – crypto: qcom-rng - ensure buffer for generate is completely filled
https://notcve.org/view.php?id=CVE-2022-48629
05 Mar 2024 — In the Linux kernel, the following vulnerability has been resolved: crypto: qcom-rng - ensure buffer for generate is completely filled The generate function in struct rng_alg expects that the destination buffer is completely filled if the function returns 0. qcom_rng_read() can run into a situation where the buffer is partially filled with randomness and the remaining part of the buffer is zeroed since qcom_rng_generate() doesn't check the return value. This issue can be reproduced by running the following ... • https://git.kernel.org/stable/c/ceec5f5b59882b871a722ca4d49b767a09a4bde9 •
CVSS: 7.8EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26622 – tomoyo: fix UAF write bug in tomoyo_write_control()
https://notcve.org/view.php?id=CVE-2024-26622
04 Mar 2024 — 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 q... • https://git.kernel.org/stable/c/bd03a3e4c9a9df0c6b007045fa7fc8889111a478 •
CVSS: 5.5EPSS: 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
02 Mar 2024 — 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.... • https://git.kernel.org/stable/c/3d3c95046742e4eebaa4b891b0b01cbbed94ebbd •
CVSS: 7.0EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52581 – netfilter: nf_tables: fix memleak when more than 255 elements expired
https://notcve.org/view.php?id=CVE-2023-52581
02 Mar 2024 — In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix memleak when more than 255 elements expired When more than 255 elements expired we're supposed to switch to a new gc container structure. This never happens: u8 type will wrap before reaching the boundary and nft_trans_gc_space() always returns true. This means we recycle the initial gc container structure and lose track of the elements that came before. While at it, don't deref 'gc' after we've passed it to call_r... • https://git.kernel.org/stable/c/5f68718b34a531a556f2f50300ead2862278da26 • CWE-401: Missing Release of Memory after Effective Lifetime •
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
02 Mar 2024 — 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... • https://git.kernel.org/stable/c/4f1cc51f34886d645cd3e8fc2915cc9b7a55c3b6 • CWE-131: Incorrect Calculation of Buffer Size •
CVSS: 7.0EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52578 – net: bridge: use DEV_STATS_INC()
https://notcve.org/view.php?id=CVE-2023-52578
02 Mar 2024 — In the Linux kernel, the following vulnerability has been resolved: net: bridge: use DEV_STATS_INC() syzbot/KCSAN reported data-races in br_handle_frame_finish() [1] This function can run from multiple cpus without mutual exclusion. Adopt SMP safe DEV_STATS_INC() to update dev->stats fields. Handles updates to dev->stats.tx_dropped while we are at it. [1] BUG: KCSAN: data-race in br_handle_frame_finish / br_handle_frame_finish read-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 1: br_handle_fram... • https://git.kernel.org/stable/c/1c29fc4989bc2a3838b2837adc12b8aeb0feeede • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52577 – dccp: fix dccp_v4_err()/dccp_v6_err() again
https://notcve.org/view.php?id=CVE-2023-52577
02 Mar 2024 — In the Linux kernel, the following vulnerability has been resolved: dccp: fix dccp_v4_err()/dccp_v6_err() again dh->dccph_x is the 9th byte (offset 8) in "struct dccp_hdr", not in the "byte 7" as Jann claimed. We need to make sure the ICMP messages are big enough, using more standard ways (no more assumptions). syzbot reported: BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2667 [inline] BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2681 [inline] BUG: KMSAN: unini... • https://git.kernel.org/stable/c/3533e10272555c422a7d51ebc0ce8c483429f7f2 •