CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52526 – erofs: fix memory leak of LZMA global compressed deduplication
https://notcve.org/view.php?id=CVE-2023-52526
In the Linux kernel, the following vulnerability has been resolved: erofs: fix memory leak of LZMA global compressed deduplication When stressing microLZMA EROFS images with the new global compressed deduplication feature enabled (`-Ededupe`), I found some short-lived temporary pages weren't properly released, which could slowly cause unexpected OOMs hours later. Let's fix it now (LZ4 and DEFLATE don't have this issue.) • https://git.kernel.org/stable/c/5c2a64252c5dc4cfe78e5b2a531c118894e3d155 https://git.kernel.org/stable/c/6a5a8f0a9740f865693d5aa97a42cc4504538e18 https://git.kernel.org/stable/c/c955751cbf864cf2055117dd3fe7f780d2a57b56 https://git.kernel.org/stable/c/75a5221630fe5aa3fedba7a06be618db0f79ba1e •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52525 – wifi: mwifiex: Fix oob check condition in mwifiex_process_rx_packet
https://notcve.org/view.php?id=CVE-2023-52525
In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix oob check condition in mwifiex_process_rx_packet Only skip the code path trying to access the rfc1042 headers when the buffer is too small, so the driver can still process packets without rfc1042 headers. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mwifiex: corrige la condición de verificación de oob en mwifiex_process_rx_packet Solo omita la ruta del código al intentar acceder a los encabezados rfc1042 cuando el búfer sea demasiado pequeño, para que el controlador aún pueda procesar paquetes sin encabezados rfc1042 . • https://git.kernel.org/stable/c/f517c97fc129995de77dd06aa5a74f909ebf568f https://git.kernel.org/stable/c/8824aa4ab62c800f75d96f48e1883a5f56ec5869 https://git.kernel.org/stable/c/29eca8b7863d1d7de6c5b746b374e3487d14f154 https://git.kernel.org/stable/c/3fe3923d092e22d87d1ed03e2729db444b8c1331 https://git.kernel.org/stable/c/7c54b6fc39eb1aac51cf2945f8a25e2a47fdca02 https://git.kernel.org/stable/c/3975e21d4d01efaf0296ded40d11c06589c49245 https://git.kernel.org/stable/c/650d1bc02fba7b42f476d8b6643324abac5921ed https://git.kernel.org/stable/c/a7300e3800e9fd5405e88ce67709c1a97 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52524 – net: nfc: llcp: Add lock when modifying device list
https://notcve.org/view.php?id=CVE-2023-52524
In the Linux kernel, the following vulnerability has been resolved: net: nfc: llcp: Add lock when modifying device list The device list needs its associated lock held when modifying it, or the list could become corrupted, as syzbot discovered. • https://git.kernel.org/stable/c/dd6ff3f3862709ab1a12566e73b9d6a9b8f6e548 https://git.kernel.org/stable/c/96f2c6f272ec04083d828de46285a7d7b17d1aad https://git.kernel.org/stable/c/fc8429f8d86801f092fbfbd257c3af821ac0dcd3 https://git.kernel.org/stable/c/425d9d3a92df7d96b3cfb7ee5c240293a21cbde3 https://git.kernel.org/stable/c/6709d4b7bc2e079241fdef15d1160581c5261c10 https://git.kernel.org/stable/c/b3ad46e155a6d91b36c6e892019a43e3ef3c696d https://git.kernel.org/stable/c/e5207c1d69b1a9707615ab6ff9376e59fc096815 https://git.kernel.org/stable/c/191d87a19cf1005ecf41e1ae08d74e173 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52523 – bpf, sockmap: Reject sk_msg egress redirects to non-TCP sockets
https://notcve.org/view.php?id=CVE-2023-52523
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Reject sk_msg egress redirects to non-TCP sockets With a SOCKMAP/SOCKHASH map and an sk_msg program user can steer messages sent from one TCP socket (s1) to actually egress from another TCP socket (s2): tcp_bpf_sendmsg(s1) // = sk_prot->sendmsg tcp_bpf_send_verdict(s1) // __SK_REDIRECT case tcp_bpf_sendmsg_redir(s2) tcp_bpf_push_locked(s2) tcp_bpf_push(s2) tcp_rate_check_app_limited(s2) // expects tcp_sock tcp_sendmsg_locked(s2) // ditto There is a hard-coded assumption in the call-chain, that the egress socket (s2) is a TCP socket. However in commit 122e6c79efe1 ("sock_map: Update sock type checks for UDP") we have enabled redirects to non-TCP sockets. This was done for the sake of BPF sk_skb programs. There was no indention to support sk_msg send-to-egress use case. As a result, attempts to send-to-egress through a non-TCP socket lead to a crash due to invalid downcast from sock to tcp_sock: BUG: kernel NULL pointer dereference, address: 000000000000002f ... Call Trace: <TASK> ? show_regs+0x60/0x70 ? __die+0x1f/0x70 ? • https://git.kernel.org/stable/c/122e6c79efe1c25816118aca9cfabe54e99c2432 https://git.kernel.org/stable/c/bc8b89b6963803a123f64aa9494155a037b3d728 https://git.kernel.org/stable/c/b8f97e47b6fb84fcf2f5a22e725eefb6cf5070c2 https://git.kernel.org/stable/c/ded6e448028f0f91b6af35985afca01fa02a9089 https://git.kernel.org/stable/c/b80e31baa43614e086a9d29dc1151932b1bd7fc5 •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52522 – net: fix possible store tearing in neigh_periodic_work()
https://notcve.org/view.php?id=CVE-2023-52522
In the Linux kernel, the following vulnerability has been resolved: net: fix possible store tearing in neigh_periodic_work() While looking at a related syzbot report involving neigh_periodic_work(), I found that I forgot to add an annotation when deleting an RCU protected item from a list. Readers use rcu_deference(*np), we need to use either rcu_assign_pointer() or WRITE_ONCE() on writer side to prevent store tearing. I use rcu_assign_pointer() to have lockdep support, this was the choice made in neigh_flush_dev(). A flaw was found in the Linux kernel that allows for potential store tearing within the neigh_periodic_work() function, meaning a write operation on a value is not protected properly and could result in inconsistencies if another process or thread reads from that value before the operation is complete. • https://git.kernel.org/stable/c/767e97e1e0db0d0f3152cd2f3bd3403596aedbad https://git.kernel.org/stable/c/95eabb075a5902f4c0834ab1fb12dc35730c05af https://git.kernel.org/stable/c/2ea52a2fb8e87067e26bbab4efb8872639240eb0 https://git.kernel.org/stable/c/147d89ee41434b97043c2dcb17a97dc151859baa https://git.kernel.org/stable/c/f82aac8162871e87027692b36af335a2375d4580 https://git.kernel.org/stable/c/a75152d233370362eebedb2643592e7c883cc9fc https://git.kernel.org/stable/c/25563b581ba3a1f263a00e8c9a97f5e7363be6fd https://access.redhat.com/security/cve/CVE-2023-52522 • CWE-20: Improper Input Validation •