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 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52520 – platform/x86: think-lmi: Fix reference leak
https://notcve.org/view.php?id=CVE-2023-52520
In the Linux kernel, the following vulnerability has been resolved: platform/x86: think-lmi: Fix reference leak If a duplicate attribute is found using kset_find_obj(), a reference to that attribute is returned which needs to be disposed accordingly using kobject_put(). Move the setting name validation into a separate function to allow for this change without having to duplicate the cleanup code for this setting. As a side note, a very similar bug was fixed in commit 7295a996fdab ("platform/x86: dell-sysman: Fix reference leak"), so it seems that the bug was copied from that driver. Compile-tested only. • https://git.kernel.org/stable/c/1bcad8e510b27ad843315ab2c27ccf459e3acded https://git.kernel.org/stable/c/124cf0ea4b82e1444ec8c7420af4e7db5558c293 https://git.kernel.org/stable/c/af21c9119a37cecb7ff27ce0c2f3cf721e9d0ec4 https://git.kernel.org/stable/c/c6e3023579de8d33256771ac0745239029e81106 https://git.kernel.org/stable/c/528ab3e605cabf2f9c9bd5944d3bfe15f6e94f81 https://access.redhat.com/security/cve/CVE-2023-52520 https://bugzilla.redhat.com/show_bug.cgi?id=2267797 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52519 – HID: intel-ish-hid: ipc: Disable and reenable ACPI GPE bit
https://notcve.org/view.php?id=CVE-2023-52519
In the Linux kernel, the following vulnerability has been resolved: HID: intel-ish-hid: ipc: Disable and reenable ACPI GPE bit The EHL (Elkhart Lake) based platforms provide a OOB (Out of band) service, which allows to wakup device when the system is in S5 (Soft-Off state). This OOB service can be enabled/disabled from BIOS settings. When enabled, the ISH device gets PME wake capability. To enable PME wakeup, driver also needs to enable ACPI GPE bit. On resume, BIOS will clear the wakeup bit. So driver need to re-enable it in resume function to keep the next wakeup capability. • https://git.kernel.org/stable/c/2e23a70edabe933284f690dff49497fb6b82b0e5 https://git.kernel.org/stable/c/8781fe259dd5a178fdd1069401bbd1437f9491c5 https://git.kernel.org/stable/c/cdcc04e844a2d22d9d25cef1e8e504a174ea9f8f https://git.kernel.org/stable/c/60fb3f054c99608ddb1f2466c07108da6292951e https://git.kernel.org/stable/c/8f02139ad9a7e6e5c05712f8c1501eebed8eacfd •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52517 – spi: sun6i: fix race between DMA RX transfer completion and RX FIFO drain
https://notcve.org/view.php?id=CVE-2023-52517
In the Linux kernel, the following vulnerability has been resolved: spi: sun6i: fix race between DMA RX transfer completion and RX FIFO drain Previously the transfer complete IRQ immediately drained to RX FIFO to read any data remaining in FIFO to the RX buffer. This behaviour is correct when dealing with SPI in interrupt mode. However in DMA mode the transfer complete interrupt still fires as soon as all bytes to be transferred have been stored in the FIFO. At that point data in the FIFO still needs to be picked up by the DMA engine. Thus the drain procedure and DMA engine end up racing to read from RX FIFO, corrupting any data read. • https://git.kernel.org/stable/c/bd1ec7f9983b5cd3c77e0f7cda3fa8aed041af2f https://git.kernel.org/stable/c/36b29974a7ad2ff604c24ad348f940506c7b1209 https://git.kernel.org/stable/c/4e149d524678431638ff378ef6025e4e89b71097 https://git.kernel.org/stable/c/1f11f4202caf5710204d334fe63392052783876d •