CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52527 – ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()
https://notcve.org/view.php?id=CVE-2023-52527
02 Mar 2024 — In the Linux kernel, the following vulnerability has been resolved: ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data() Including the transhdrlen in length is a problem when the packet is partially filled (e.g. something like send(MSG_MORE) happened previously) when appending to an IPv4 or IPv6 packet as we don't want to repeat the transport header or account for it twice. This can happen under some circumstances, such as splicing into an L2TP socket. The symptom observed is a warning in __ip6... • https://git.kernel.org/stable/c/a32e0eec7042b21ccb52896cf715e3e2641fed93 •
CVSS: 3.5EPSS: 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
02 Mar 2024 — 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 encabezad... • https://git.kernel.org/stable/c/f517c97fc129995de77dd06aa5a74f909ebf568f •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52524 – net: nfc: llcp: Add lock when modifying device list
https://notcve.org/view.php?id=CVE-2023-52524
02 Mar 2024 — 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. 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 •
CVSS: 5.5EPSS: 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
02 Mar 2024 — 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(s... • https://git.kernel.org/stable/c/122e6c79efe1c25816118aca9cfabe54e99c2432 •
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
02 Mar 2024 — 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_flu... • https://git.kernel.org/stable/c/767e97e1e0db0d0f3152cd2f3bd3403596aedbad • 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
02 Mar 2024 — 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... • https://git.kernel.org/stable/c/1bcad8e510b27ad843315ab2c27ccf459e3acded •
CVSS: 5.5EPSS: 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
02 Mar 2024 — 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. • https://git.kernel.org/stable/c/2e23a70edabe933284f690dff49497fb6b82b0e5 •
CVSS: 5.5EPSS: 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
02 Mar 2024 — 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 ... • https://git.kernel.org/stable/c/bd1ec7f9983b5cd3c77e0f7cda3fa8aed041af2f •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52516 – dma-debug: don't call __dma_entry_alloc_check_leak() under free_entries_lock
https://notcve.org/view.php?id=CVE-2023-52516
02 Mar 2024 — In the Linux kernel, the following vulnerability has been resolved: dma-debug: don't call __dma_entry_alloc_check_leak() under free_entries_lock __dma_entry_alloc_check_leak() calls into printk -> serial console output (qcom geni) and grabs port->lock under free_entries_lock spin lock, which is a reverse locking dependency chain as qcom_geni IRQ handler can call into dma-debug code and grab free_entries_lock under port->lock. Move __dma_entry_alloc_check_leak() call out of free_entries_lock scope so that we... • https://git.kernel.org/stable/c/c79300599923daaa30f417c75555d5566b3d31ae •
CVSS: 7.8EPSS: 0%CPEs: 10EXPL: 0CVE-2023-52515 – RDMA/srp: Do not call scsi_done() from srp_abort()
https://notcve.org/view.php?id=CVE-2023-52515
02 Mar 2024 — In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: Do not call scsi_done() from srp_abort() After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler callback, it performs one of the following actions: * Call scsi_queue_insert(). * Call scsi_finish_command(). * Call scsi_eh_scmd_add(). Hence, SCSI abort handlers must not call scsi_done(). Otherwise all the above actions would trigger a use-after-free. Hence remove the scsi_done() call from srp_abort(). Keep the srp_fr... • https://git.kernel.org/stable/c/d8536670916a685df116b5c2cb256573fd25e4e3 •