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: 5.5EPSS: 0%CPEs: 13EXPL: 0CVE-2024-26629 – nfsd: fix RELEASE_LOCKOWNER
https://notcve.org/view.php?id=CVE-2024-26629
In the Linux kernel, the following vulnerability has been resolved: nfsd: fix RELEASE_LOCKOWNER The test on so_count in nfsd4_release_lockowner() is nonsense and harmful. Revert to using check_for_locks(), changing that to not sleep. First: harmful. As is documented in the kdoc comment for nfsd4_release_lockowner(), the test on so_count can transiently return a false positive resulting in a return of NFS4ERR_LOCKS_HELD when in fact no locks are held. This is clearly a protocol violation and with the Linux NFS client it can cause incorrect behaviour. If RELEASE_LOCKOWNER is sent while some other thread is still processing a LOCK request which failed because, at the time that request was received, the given owner held a conflicting lock, then the nfsd thread processing that LOCK request can hold a reference (conflock) to the lock owner that causes nfsd4_release_lockowner() to return an incorrect error. The Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because it never sends NFS4_RELEASE_LOCKOWNER without first releasing any locks, so it knows that the error is impossible. It assumes the lock owner was in fact released so it feels free to use the same lock owner identifier in some later locking request. When it does reuse a lock owner identifier for which a previous RELEASE failed, it will naturally use a lock_seqid of zero. However the server, which didn't release the lock owner, will expect a larger lock_seqid and so will respond with NFS4ERR_BAD_SEQID. So clearly it is harmful to allow a false positive, which testing so_count allows. The test is nonsense because ... well... it doesn't mean anything. so_count is the sum of three different counts. 1/ the set of states listed on so_stateids 2/ the set of active vfs locks owned by any of those states 3/ various transient counts such as for conflicting locks. When it is tested against '2' it is clear that one of these is the transient reference obtained by find_lockowner_str_locked(). • https://git.kernel.org/stable/c/3097f38e91266c7132c3fdb7e778fac858c00670 https://git.kernel.org/stable/c/e2fc17fcc503cfca57b5d1dd3b646ca7eebead97 https://git.kernel.org/stable/c/ce3c4ad7f4ce5db7b4f08a1e237d8dd94b39180b https://git.kernel.org/stable/c/fea1d0940301378206955264a01778700fc9c16f https://git.kernel.org/stable/c/2ec65dc6635d1976bd1dbf2640ff7f810b2f6dd1 https://git.kernel.org/stable/c/ef481b262bba4f454351eec43f024fec942c2d4c https://git.kernel.org/stable/c/10d75984495f7fe62152c3b0dbfa3f0a6b739c9b https://git.kernel.org/stable/c/a2235bc65ade40982c3d09025cdd34bc5 • CWE-393: Return of Wrong Status Code •