CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52612 – crypto: scomp - fix req->dst buffer overflow
https://notcve.org/view.php?id=CVE-2023-52612
In the Linux kernel, the following vulnerability has been resolved: crypto: scomp - fix req->dst buffer overflow The req->dst buffer size should be checked before copying from the scomp_scratch->dst to avoid req->dst buffer overflow problem. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: scomp - corrige el desbordamiento del búfer req->dst. El tamaño del búfer req->dst debe verificarse antes de copiar desde scomp_scratch->dst para evitar el problema de desbordamiento del búfer req->dst. . • https://git.kernel.org/stable/c/1ab53a77b772bf7369464a0e4fa6fd6499acf8f1 https://git.kernel.org/stable/c/1142d65c5b881590962ad763f94505b6dd67d2fe https://git.kernel.org/stable/c/e0e3f4a18784182cfe34e20c00eca11e78d53e76 https://git.kernel.org/stable/c/4518dc468cdd796757190515a9be7408adc8911e https://git.kernel.org/stable/c/a5f2f91b3fd7387e5102060809316a0f8f0bc625 https://git.kernel.org/stable/c/4df0c942d04a67df174195ad8082f6e30e7f71a5 https://git.kernel.org/stable/c/7d9e5bed036a7f9e2062a137e97e3c1e77fb8759 https://git.kernel.org/stable/c/71c6670f9f032ec67d8f4e3f8db4646bf •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52611 – wifi: rtw88: sdio: Honor the host max_req_size in the RX path
https://notcve.org/view.php?id=CVE-2023-52611
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: sdio: Honor the host max_req_size in the RX path Lukas reports skb_over_panic errors on his Banana Pi BPI-CM4 which comes with an Amlogic A311D (G12B) SoC and a RTL8822CS SDIO wifi/Bluetooth combo card. The error he observed is identical to what has been fixed in commit e967229ead0e ("wifi: rtw88: sdio: Check the HISR RX_REQUEST bit in rtw_sdio_rx_isr()") but that commit didn't fix Lukas' problem. Lukas found that disabling or limiting RX aggregation works around the problem for some time (but does not fully fix it). In the following discussion a few key topics have been discussed which have an impact on this problem: - The Amlogic A311D (G12B) SoC has a hardware bug in the SDIO controller which prevents DMA transfers. Instead all transfers need to go through the controller SRAM which limits transfers to 1536 bytes - rtw88 chips don't split incoming (RX) packets, so if a big packet is received this is forwarded to the host in it's original form - rtw88 chips can do RX aggregation, meaning more multiple incoming packets can be pulled by the host from the card with one MMC/SDIO transfer. This Depends on settings in the REG_RXDMA_AGG_PG_TH register (BIT_RXDMA_AGG_PG_TH limits the number of packets that will be aggregated, BIT_DMA_AGG_TO_V1 configures a timeout for aggregation and BIT_EN_PRE_CALC makes the chip honor the limits more effectively) Use multiple consecutive reads in rtw_sdio_read_port() and limit the number of bytes which are copied by the host from the card in one MMC/SDIO transfer. • https://git.kernel.org/stable/c/65371a3f14e73979958aea0db1e3bb456a296149 https://git.kernel.org/stable/c/5b5ddf21b978ec315cab9d9e7e6ac7374791a8c7 https://git.kernel.org/stable/c/0e9ffff72a0674cd6656314dbd99cdd2123a3030 https://git.kernel.org/stable/c/00384f565a91c08c4bedae167f749b093d10e3fe •
CVSS: 6.4EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52610 – net/sched: act_ct: fix skb leak and crash on ooo frags
https://notcve.org/view.php?id=CVE-2023-52610
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: fix skb leak and crash on ooo frags act_ct adds skb->users before defragmentation. If frags arrive in order, the last frag's reference is reset in: inet_frag_reasm_prepare skb_morph which is not straightforward. However when frags arrive out of order, nobody unref the last frag, and all frags are leaked. The situation is even worse, as initiating packet capture can lead to a crash[0] when skb has been cloned and shared at the same time. Fix the issue by removing skb_get() before defragmentation. act_ct returns TC_ACT_CONSUMED when defrag failed or in progress. [0]: [ 843.804823] ------------[ cut here ]------------ [ 843.809659] kernel BUG at net/core/skbuff.c:2091! [ 843.814516] invalid opcode: 0000 [#1] PREEMPT SMP [ 843.819296] CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G S 6.7.0-rc3 #2 [ 843.824107] Hardware name: XFUSION 1288H V6/BC13MBSBD, BIOS 1.29 11/25/2022 [ 843.828953] RIP: 0010:pskb_expand_head+0x2ac/0x300 [ 843.833805] Code: 8b 70 28 48 85 f6 74 82 48 83 c6 08 bf 01 00 00 00 e8 38 bd ff ff 8b 83 c0 00 00 00 48 03 83 c8 00 00 00 e9 62 ff ff ff 0f 0b <0f> 0b e8 8d d0 ff ff e9 b3 fd ff ff 81 7c 24 14 40 01 00 00 4c 89 [ 843.843698] RSP: 0018:ffffc9000cce07c0 EFLAGS: 00010202 [ 843.848524] RAX: 0000000000000002 RBX: ffff88811a211d00 RCX: 0000000000000820 [ 843.853299] RDX: 0000000000000640 RSI: 0000000000000000 RDI: ffff88811a211d00 [ 843.857974] RBP: ffff888127d39518 R08: 00000000bee97314 R09: 0000000000000000 [ 843.862584] R10: 0000000000000000 R11: ffff8881109f0000 R12: 0000000000000880 [ 843.867147] R13: ffff888127d39580 R14: 0000000000000640 R15: ffff888170f7b900 [ 843.871680] FS: 0000000000000000(0000) GS:ffff889ffffc0000(0000) knlGS:0000000000000000 [ 843.876242] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 843.880778] CR2: 00007fa42affcfb8 CR3: 000000011433a002 CR4: 0000000000770ef0 [ 843.885336] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 843.889809] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 843.894229] PKRU: 55555554 [ 843.898539] Call Trace: [ 843.902772] <IRQ> [ 843.906922] ? __die_body+0x1e/0x60 [ 843.911032] ? • https://git.kernel.org/stable/c/b57dc7c13ea90e09ae15f821d2583fa0231b4935 https://git.kernel.org/stable/c/172ba7d46c202e679f3ccb10264c67416aaeb1c4 https://git.kernel.org/stable/c/0b5b831122fc3789fff75be433ba3e4dd7b779d4 https://git.kernel.org/stable/c/73f7da5fd124f2cda9161e2e46114915e6e82e97 https://git.kernel.org/stable/c/f5346df0591d10bc948761ca854b1fae6d2ef441 https://git.kernel.org/stable/c/3f14b377d01d8357eba032b4cabc8c1149b458b6 https://access.redhat.com/security/cve/CVE-2023-52610 https://bugzilla.redhat.com/show_bug.cgi?id=2270080 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52609 – binder: fix race between mmput() and do_exit()
https://notcve.org/view.php?id=CVE-2023-52609
In the Linux kernel, the following vulnerability has been resolved: binder: fix race between mmput() and do_exit() Task A calls binder_update_page_range() to allocate and insert pages on a remote address space from Task B. For this, Task A pins the remote mm via mmget_not_zero() first. This can race with Task B do_exit() and the final mmput() refcount decrement will come from Task A. Task A | Task B ------------------+------------------ mmget_not_zero() | | do_exit() | exit_mm() | mmput() mmput() | exit_mmap() | remove_vma() | fput() | In this case, the work of ____fput() from Task B is queued up in Task A as TWA_RESUME. So in theory, Task A returns to userspace and the cleanup work gets executed. However, Task A instead sleep, waiting for a reply from Task B that never comes (it's dead). This means the binder_deferred_release() is blocked until an unrelated binder event forces Task A to go back to userspace. • https://git.kernel.org/stable/c/457b9a6f09f011ebcb9b52cc203a6331a6fc2de7 https://git.kernel.org/stable/c/95b1d336b0642198b56836b89908d07b9a0c9608 https://git.kernel.org/stable/c/252a2a5569eb9f8d16428872cc24dea1ac0bb097 https://git.kernel.org/stable/c/7e7a0d86542b0ea903006d3f42f33c4f7ead6918 https://git.kernel.org/stable/c/98fee5bee97ad47b527a997d5786410430d1f0e9 https://git.kernel.org/stable/c/6696f76c32ff67fec26823fc2df46498e70d9bf3 https://git.kernel.org/stable/c/67f16bf2cc1698fd50e01ee8a2becc5a8e6d3a3e https://git.kernel.org/stable/c/77d210e8db4d61d43b2d16df66b1ec46f •
CVSS: 7.1EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26630 – mm: cachestat: fix folio read-after-free in cache walk
https://notcve.org/view.php?id=CVE-2024-26630
In the Linux kernel, the following vulnerability has been resolved: mm: cachestat: fix folio read-after-free in cache walk In cachestat, we access the folio from the page cache's xarray to compute its page offset, and check for its dirty and writeback flags. However, we do not hold a reference to the folio before performing these actions, which means the folio can concurrently be released and reused as another folio/page/slab. Get around this altogether by just using xarray's existing machinery for the folio page offsets and dirty/writeback states. This changes behavior for tmpfs files to now always report zeroes in their dirty and writeback counters. This is okay as tmpfs doesn't follow conventional writeback cache behavior: its pages get "cleaned" during swapout, after which they're no longer resident etc. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: cachestat: corrige read-after-free la publicación en cache walk En cachestat, accedemos a la publicación desde la matriz x de la caché de la página para calcular su desplazamiento de página y comprobar si está sucia y banderas de reescritura. Sin embargo, no mantenemos una referencia al folio antes de realizar estas acciones, lo que significa que el folio se puede liberar y reutilizar simultáneamente como otro folio/página/losa. • https://git.kernel.org/stable/c/cf264e1329fb0307e044f7675849f9f38b44c11a https://git.kernel.org/stable/c/ba60fdf75e89ea762bb617be578dc47f27655117 https://git.kernel.org/stable/c/fe7e008e0ce728252e4ec652cceebcc62211657c https://git.kernel.org/stable/c/3a75cb05d53f4a6823a32deb078de1366954a804 https://access.redhat.com/security/cve/CVE-2024-26630 https://bugzilla.redhat.com/show_bug.cgi?id=2269436 • CWE-416: Use After Free •