Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2025-23137 State: PUBLISHED Published: 2025-04-16T14:13:17.061Z Last Updated: 2025-06-27T10:21:17.423Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cpufreq/amd-pstate: Add missing NULL ptr check in amd_pstate_update Check if policy is NULL before dereferencing it in amd_pstate_update. References: - https://git.kernel.org/stable/c/82b6dfff0d6000b14b271f74e43d672d81fb390e - https://git.kernel.org/stable/c/b99c1c63d88c75a4dc5487c3696cda38697b8d35 - https://git.kernel.org/stable/c/426db24d4db2e4f0d6720aeb7795eafcb9e82640
CVE ID: CVE-2025-23138 State: PUBLISHED Published: 2025-04-16T14:13:17.866Z Last Updated: 2025-11-03T19:42:22.845Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: watch_queue: fix pipe accounting mismatch Currently, watch_queue_set_size() modifies the pipe buffers charged to user->pipe_bufs without updating the pipe->nr_accounted on the pipe itself, due to the if (!pipe_has_watch_queue()) test in pipe_resize_ring(). This means that when the pipe is ultimately freed, we decrement user->pipe_bufs by something other than what than we had charged to it, potentially leading to an underflow. This in turn can cause subsequent too_many_
er than what than we had charged to it, potentially leading to an underflow. This in turn can cause subsequent too_many_pipe_buffers_soft() tests to fail with -EPERM. To remedy this, explicitly account for the pipe usage in watch_queue_set_size() to match the number set via account_pipe_buffers() (It's unclear why watch_queue_set_size() does not update nr_accounted; it may be due to intentional overprovisioning in watch_queue_set_size()?) Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/8658c75343ed00e5e154ebbe24335f51ba8db547 - https://git.kernel.org/stable/c/471c89b7d4f58bd6082f7c1fe14d4ca15c7f1284 - https://git.kernel.org/stable/c/d40e353726
- https://git.kernel.org/stable/c/471c89b7d4f58bd6082f7c1fe14d4ca15c7f1284 - https://git.kernel.org/stable/c/d40e3537265dea9e3c33021874437ff26dc18787 - https://git.kernel.org/stable/c/6dafa27764183738dc5368b669b71e3d0d154f12 - https://git.kernel.org/stable/c/56ec918e6c86c1536870e4373e91eddd0c44245f - https://git.kernel.org/stable/c/2d680b988656bb556c863d8b46d9b9096842bf3d - https://git.kernel.org/stable/c/205028ebba838938d3b264dda1d0708fa7fe1ade - https://git.kernel.org/stable/c/f13abc1e8e1a3b7455511c4e122750127f6bc9b0
CVE ID: CVE-2025-23139 State: REJECTED Published: 2025-05-01T12:55:30.196Z Last Updated: 2025-05-08T10:24:36.037Z Description: No description available.
CVE ID: CVE-2025-23140 State: PUBLISHED Published: 2025-05-01T12:55:30.885Z Last Updated: 2025-11-03T19:42:25.618Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: misc: pci_endpoint_test: Avoid issue of interrupts remaining after request_irq error After devm_request_irq() fails with error in pci_endpoint_test_request_irq(), the pci_endpoint_test_free_irq_vectors() is called assuming that all IRQs have been released. However, some requested IRQs remain unreleased, so there are still /proc/irq/* entries remaining, and this results in WARN() with the following message: remove_proc_entry: removing non-empty directory 'irq/30', leaki
, and this results in WARN() with the following message: remove_proc_entry: removing non-empty directory 'irq/30', leaking at least 'pci-endpoint-test.0' WARNING: CPU: 0 PID: 202 at fs/proc/generic.c:719 remove_proc_entry +0x190/0x19c To solve this issue, set the number of remaining IRQs to test->num_irqs, and release IRQs in advance by calling pci_endpoint_test_release_irq(). [kwilczynski: commit log] Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/705be96504779e4a333ea042b4779ea941f0ace9 - https://git.kernel.org/stable/c/e516e187bf32d8decc7c7d0025ae4857cad13c0e - https://git.kernel.org/stable/c/54c9f299ad7d7c4be5d271ed12d01a59e95b8907 - http
16e187bf32d8decc7c7d0025ae4857cad13c0e - https://git.kernel.org/stable/c/54c9f299ad7d7c4be5d271ed12d01a59e95b8907 - https://git.kernel.org/stable/c/9d5118b107b1a2353ed0dff24404aee2e6b7ca0a - https://git.kernel.org/stable/c/5a4b7181213268c9b07bef8800905528435db44a - https://git.kernel.org/stable/c/0557e70e2aeba8647bf5a950820b67cfb86533db - https://git.kernel.org/stable/c/770407f6173f4f39f4e2c1b54422b79ce6c98bdb - https://git.kernel.org/stable/c/f6cb7828c8e17520d4f5afb416515d3fae1af9a9
CVE ID: CVE-2025-23141 State: PUBLISHED Published: 2025-05-01T12:55:31.525Z Last Updated: 2025-11-03T19:42:27.035Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses Acquire a lock on kvm->srcu when userspace is getting MP state to handle a rather extreme edge case where "accepting" APIC events, i.e. processing pending INIT or SIPI, can trigger accesses to guest memory. If the vCPU is in L2 with INIT *and* a TRIPLE_FAULT request pending, then getting MP state will trigger a nested VM-Exit by way of ->check_nested_events(), and emuating the nested VM-Exit ca
hen getting MP state will trigger a nested VM-Exit by way of ->check_nested_events(), and emuating the nested VM-Exit can access guest memory. The splat was originally hit by syzkaller on a Google-internal kernel, and reproduced on an upstream kernel by hacking the triple_fault_event_test selftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a memory access on VMX), and do vcpu_mp_state_get() to trigger the scenario. ============================= WARNING: suspicious RCU usage 6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted ----------------------------- include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage! other info that might help us d
---------------- include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by triple_fault_ev/1256: #0: ffff88810df5a330 (&vcpu->mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm] stack backtrace: CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dump_stack_lvl+0x7f/0x90 lockdep_rcu_suspicious+0x144/0x190 kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm] kvm_vcpu_read_guest+0x3e/0x90 [kvm] read_and_check_msr_entry+0x2e/0x180 [kvm_intel] __nested_vmx_vme
t+0x156/0x180 [kvm] kvm_vcpu_read_guest+0x3e/0x90 [kvm] read_and_check_msr_entry+0x2e/0x180 [kvm_intel] __nested_vmx_vmexit+0x550/0xde0 [kvm_intel] kvm_check_nested_events+0x1b/0x30 [kvm] kvm_apic_accept_events+0x33/0x100 [kvm] kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm] kvm_vcpu_ioctl+0x33e/0x9a0 [kvm] __x64_sys_ioctl+0x8b/0xb0 do_syscall_64+0x6c/0x170 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/0357c8406dfa09430dd9858ebe813feb65524b6e - https://git.kernel.org/stable/c/8a3df0aa1087a89f5ce55f4aba816bfcb1ecf1be - https://git.kernel.org/stable/c/7bc5c360375d28ba5ef6298b0d53e735c81d66a1 -
c/8a3df0aa1087a89f5ce55f4aba816bfcb1ecf1be - https://git.kernel.org/stable/c/7bc5c360375d28ba5ef6298b0d53e735c81d66a1 - https://git.kernel.org/stable/c/f5cbe725b7477b4cd677be1b86b4e08f90572997 - https://git.kernel.org/stable/c/592e040572f216d916f465047c8ce4a308fcca44 - https://git.kernel.org/stable/c/ef01cac401f18647d62720cf773d7bb0541827da
CVE ID: CVE-2025-23142 State: PUBLISHED Published: 2025-05-01T12:55:32.614Z Last Updated: 2025-11-03T19:42:29.798Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sctp: detect and prevent references to a freed transport in sendmsg sctp_sendmsg() re-uses associations and transports when possible by doing a lookup based on the socket endpoint and the message destination address, and then sctp_sendmsg_to_asoc() sets the selected transport in all the message chunks to be sent. There's a possible race condition if another thread triggers the removal of that selected transport, for instance, by explicitly unbinding an address with set
nother thread triggers the removal of that selected transport, for instance, by explicitly unbinding an address with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks have been set up and before the message is sent. This can happen if the send buffer is full, during the period when the sender thread temporarily releases the socket lock in sctp_wait_for_sndbuf(). This causes the access to the transport data in sctp_outq_select_transport(), when the association outqueue is flushed, to result in a use-after-free read. This change avoids this scenario by having sctp_transport_free() signal the freeing of the transport, tagging it as "dead". In order to do this, the patch restores the "dead" b
t_free() signal the freeing of the transport, tagging it as "dead". In order to do this, the patch restores the "dead" bit in struct sctp_transport, which was removed in commit 47faa1e4c50e ("sctp: remove the dead field of sctp_transport"). Then, in the scenario where the sender thread has released the socket lock in sctp_wait_for_sndbuf(), the bit is checked again after re-acquiring the socket lock to detect the deletion. This is done while holding a reference to the transport to prevent it from being freed in the process. If the transport was deleted while the socket lock was relinquished, sctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry the send. The bug was found by a pr
was relinquished, sctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry the send. The bug was found by a private syzbot instance (see the error report [1] and the C reproducer that triggers it [2]). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/547762250220325d350d0917a7231480e0f4142b - https://git.kernel.org/stable/c/3257386be6a7eb8a8bfc9cbfb746df4eb4fc70e8 - https://git.kernel.org/stable/c/0f7df4899299ce4662e5f95badb9dbc57cc37fa5 - https://git.kernel.org/stable/c/7a63f4fb0efb4e69efd990cbb740a848679ec4b0 - https://git.kernel.org/stable/c/c6fefcb71d246baaf3bacdad1af7ff50ebcfe652 - https://git.kernel.org/stable/c/9e7c37fadb3be1fc
ps://git.kernel.org/stable/c/c6fefcb71d246baaf3bacdad1af7ff50ebcfe652 - https://git.kernel.org/stable/c/9e7c37fadb3be1fc33073fcf10aa96d166caa697 - https://git.kernel.org/stable/c/5bc83bdf5f5b8010d1ca5a4555537e62413ab4e2 - https://git.kernel.org/stable/c/2e5068b7e0ae0a54f6cfd03a2f80977da657f1ee - https://git.kernel.org/stable/c/f1a69a940de58b16e8249dff26f74c8cc59b32be
CVE ID: CVE-2025-23143 State: PUBLISHED Published: 2025-05-01T12:55:33.348Z Last Updated: 2025-11-03T17:32:14.894Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: Fix null-ptr-deref by sock_lock_init_class_and_name() and rmmod. When I ran the repro [0] and waited a few seconds, I observed two LOCKDEP splats: a warning immediately followed by a null-ptr-deref. [1] Reproduction Steps: 1) Mount CIFS 2) Add an iptables rule to drop incoming FIN packets for CIFS 3) Unmount CIFS 4) Unload the CIFS module 5) Remove the iptables rule At step 3), the CIFS module calls sock_release() for the underlying TCP socket, and it returns quic
ve the iptables rule At step 3), the CIFS module calls sock_release() for the underlying TCP socket, and it returns quickly. However, the socket remains in FIN_WAIT_1 because incoming FIN packets are dropped. At this point, the module's refcnt is 0 while the socket is still alive, so the following rmmod command succeeds. # ss -tan State Recv-Q Send-Q Local Address:Port Peer Address:Port FIN-WAIT-1 0 477 10.0.2.15:51062 10.0.0.137:445 # lsmod | grep cifs cifs 1159168 0 This highlights a discrepancy between the lifetime of the CIFS module and the underlying TCP socket. Even after CIFS calls sock_release() and it returns, the TCP socket does not die immediately in order to close the connection
fter CIFS calls sock_release() and it returns, the TCP socket does not die immediately in order to close the connection gracefully. While this is generally fine, it causes an issue with LOCKDEP because CIFS assigns a different lock class to the TCP socket's sk->sk_lock using sock_lock_init_class_and_name(). Once an incoming packet is processed for the socket or a timer fires, sk->sk_lock is acquired. Then, LOCKDEP checks the lock context in check_wait_context(), where hlock_class() is called to retrieve the lock class. However, since the module has already been unloaded, hlock_class() logs a warning and returns NULL, triggering the null-ptr-deref. If LOCKDEP is enabled, we must ensure that a
ock_class() logs a warning and returns NULL, triggering the null-ptr-deref. If LOCKDEP is enabled, we must ensure that a module calling sock_lock_init_class_and_name() (CIFS, NFS, etc) cannot be unloaded while such a socket is still alive to prevent this issue. Let's hold the module reference in sock_lock_init_class_and_name() and release it when the socket is freed in sk_prot_free(). Note that sock_lock_init() clears sk->sk_owner for svc_create_socket() that calls sock_lock_init_class_and_name() for a listening socket, which clones a socket by sk_clone_lock() without GFP_ZERO. [0]: CIFS_SERVER="10.0.0.137" CIFS_PATH="//${CIFS_SERVER}/Users/Administrator/Desktop/CIFS_TEST" DEV="enp0s3" CRED=
ERO. [0]: CIFS_SERVER="10.0.0.137" CIFS_PATH="//${CIFS_SERVER}/Users/Administrator/Desktop/CIFS_TEST" DEV="enp0s3" CRED="/root/WindowsCredential.txt" MNT=$(mktemp -d /tmp/XXXXXX) mount -t cifs ${CIFS_PATH} ${MNT} -o vers=3.0,credentials=${CRED},cache=none,echo_interval=1 iptables -A INPUT -s ${CIFS_SERVER} -j DROP for i in $(seq 10); do umount ${MNT} rmmod cifs sleep 1 done rm -r ${MNT} iptables -D INPUT -s ${CIFS_SERVER} -j DROP [1]: DEBUG_LOCKS_WARN_ON(1) WARNING: CPU: 10 PID: 0 at kernel/locking/lockdep.c:234 hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) Modules linked in: cifs_arc4 nls_ucs2_utils cifs_md4 [last unloaded: cifs] CPU: 10 UID: 0 PID: 0 Comm: swapper
ep.c:223) Modules linked in: cifs_arc4 nls_ucs2_utils cifs_md4 [last unloaded: cifs] CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Not tainted 6.14.0 #36 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) ... Call Trace: <IRQ> __lock_acquire (kernel/locking/lockdep.c:4853 kernel/locking/lockdep.c:5178) lock_acquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853 kernel/locking/lockdep.c:5816) _raw_spin_lock_nested (kernel/locking/spinlock.c:379) tcp_v4_rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcp_ipv4.c:2350) ... B
cking/spinlock.c:379) tcp_v4_rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcp_ipv4.c:2350) ... BUG: kernel NULL pointer dereference, address: 00000000000000c4 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Tainted: G W 6.14.0 #36 Tainted: [W]=WARN Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__lock_acquire (kernel/ ---truncated--- Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/83083c5fc7cf9b0f136a42f26aba60da380f3601 -
otes: - CVE Program Container: References: - https://git.kernel.org/stable/c/83083c5fc7cf9b0f136a42f26aba60da380f3601 - https://git.kernel.org/stable/c/b7489b753667bc9245958a4896c9419743083c27 - https://git.kernel.org/stable/c/d51e47e2ab6ef10a317d576075cf625cdbf96426 - https://git.kernel.org/stable/c/feda73ad44a5cc80f6bf796bb1099a3fe71576d4 - https://git.kernel.org/stable/c/905d43b8ad2436c240f844acb3ebcc7a99b8ebf1 - https://git.kernel.org/stable/c/5f7f6abd92b6c8dc8f19625ef93c3a18549ede04 - https://git.kernel.org/stable/c/c11247a21aab4b50a23c8b696727d7483de2f1e1 - https://git.kernel.org/stable/c/2155802d3313d7b8365935c6b8d6edc0ddd7eb94 - https://git.kernel.org/stable/c/0bb2f7a1ad1f11d861f58e5
t.kernel.org/stable/c/2155802d3313d7b8365935c6b8d6edc0ddd7eb94 - https://git.kernel.org/stable/c/0bb2f7a1ad1f11d861f58e5ee5051c8974ff9569
CVE ID: CVE-2025-23144 State: PUBLISHED Published: 2025-05-01T12:55:33.985Z Last Updated: 2025-11-03T19:42:32.577Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: backlight: led_bl: Hold led_access lock when calling led_sysfs_disable() Lockdep detects the following issue on led-backlight removal: [ 142.315935] ------------[ cut here ]------------ [ 142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80 ... [ 142.500725] Call trace: [ 142.503176] led_sysfs_enable+0x54/0x80 (P) [ 142.507370] led_bl_remove+0x80/0xa8 [led_bl] [ 142.511742] platform_remove+0x30/0x58 [ 142.515501] device_remove+
(P) [ 142.507370] led_bl_remove+0x80/0xa8 [led_bl] [ 142.511742] platform_remove+0x30/0x58 [ 142.515501] device_remove+0x54/0x90 ... Indeed, led_sysfs_enable() has to be called with the led_access lock held. Hold the lock when calling led_sysfs_disable(). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/87d947a0607be384bfe7bb0935884a711e35ca07 - https://git.kernel.org/stable/c/74c7d67a3c305fc1fa03c32a838e8446fb7aee14 - https://git.kernel.org/stable/c/b447885ec9130cf86f355e011dc6b94d6ccfb5b7 - https://git.kernel.org/stable/c/1c82f5a393d8b9a5c1ea032413719862098afd4b - https://git.kernel.org/stable/c/61a5c565fd2442d3128f3bab5f022658adc3a4e6 - htt
c82f5a393d8b9a5c1ea032413719862098afd4b - https://git.kernel.org/stable/c/61a5c565fd2442d3128f3bab5f022658adc3a4e6 - https://git.kernel.org/stable/c/11d128f7eacec276c75cf4712880a6307ca9c885 - https://git.kernel.org/stable/c/b8ddf5107f53789448900f04fa220f34cd2f777e - https://git.kernel.org/stable/c/276822a00db3c1061382b41e72cafc09d6a0ec30
CVE ID: CVE-2025-23145 State: PUBLISHED Published: 2025-05-01T12:55:34.622Z Last Updated: 2025-11-03T19:42:35.316Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mptcp: fix NULL pointer in can_accept_new_subflow When testing valkey benchmark tool with MPTCP, the kernel panics in 'mptcp_can_accept_new_subflow' because subflow_req->msk is NULL. Call trace: mptcp_can_accept_new_subflow (./net/mptcp/subflow.c:63 (discriminator 4)) (P) subflow_syn_recv_sock (./net/mptcp/subflow.c:854) tcp_check_req (./net/ipv4/tcp_minisocks.c:863) tcp_v4_rcv (./net/ipv4/tcp_ipv4.c:2268) ip_protocol_deliver_rcu (./net/ipv4/ip_input.c:207) ip_local_de
minisocks.c:863) tcp_v4_rcv (./net/ipv4/tcp_ipv4.c:2268) ip_protocol_deliver_rcu (./net/ipv4/ip_input.c:207) ip_local_deliver_finish (./net/ipv4/ip_input.c:234) ip_local_deliver (./net/ipv4/ip_input.c:254) ip_rcv_finish (./net/ipv4/ip_input.c:449) ... According to the debug log, the same req received two SYN-ACK in a very short time, very likely because the client retransmits the syn ack due to multiple reasons. Even if the packets are transmitted with a relevant time interval, they can be processed by the server on different CPUs concurrently). The 'subflow_req->msk' ownership is transferred to the subflow the first, and there will be a risk of a null pointer dereference here. This patch fi
ship is transferred to the subflow the first, and there will be a risk of a null pointer dereference here. This patch fixes this issue by moving the 'subflow_req->msk' under the `own_req == true` conditional. Note that the !msk check in subflow_hmac_valid() can be dropped, because the same check already exists under the own_req mpj branch where the code has been moved to. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/8cf7fef1bb2ffea7792bcbf71ca00216cecc725d - https://git.kernel.org/stable/c/b3088bd2a6790c8efff139d86d7a9d0b1305977b - https://git.kernel.org/stable/c/855bf0aacd51fced11ea9aa0d5101ee0febaeadb - https://git.kernel.org/stable/c/7f9
305977b - https://git.kernel.org/stable/c/855bf0aacd51fced11ea9aa0d5101ee0febaeadb - https://git.kernel.org/stable/c/7f9ae060ed64aef8f174c5f1ea513825b1be9af1 - https://git.kernel.org/stable/c/dc81e41a307df523072186b241fa8244fecd7803 - https://git.kernel.org/stable/c/efd58a8dd9e7a709a90ee486a4247c923d27296f - https://git.kernel.org/stable/c/4b2649b9717678aeb097893cc49f59311a1ecab0 - https://git.kernel.org/stable/c/443041deb5ef6a1289a99ed95015ec7442f141dc
CVE ID: CVE-2025-23146 State: PUBLISHED Published: 2025-05-01T12:55:35.284Z Last Updated: 2025-11-03T19:42:38.073Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mfd: ene-kb3930: Fix a potential NULL pointer dereference The off_gpios could be NULL. Add missing check in the kb3930_probe(). This is similar to the issue fixed in commit b1ba8bcb2d1f ("backlight: hx8357: Fix potential NULL pointer dereference"). This was detected by our static analysis tool. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/6dc88993ee3fa8365ff6a5d6514702f70ba6863a - https://git.kernel.org/stable/c/90ee2
nces: - https://git.kernel.org/stable/c/6dc88993ee3fa8365ff6a5d6514702f70ba6863a - https://git.kernel.org/stable/c/90ee23c2514a22a9c2bb39a540cbe1c9acb27d0b - https://git.kernel.org/stable/c/2edb5b29b197d90b4d08cd45e911c0bcf24cb895 - https://git.kernel.org/stable/c/ea07760676bba49319d553af80c239da053b5fb1 - https://git.kernel.org/stable/c/7b47df6498f223c8956bfe0d994a0e42a520dfcd - https://git.kernel.org/stable/c/b1758417310d2cc77e52cd15103497e52e2614f6 - https://git.kernel.org/stable/c/76d0f4199bc5b51acb7b96c6663a8953543733ad - https://git.kernel.org/stable/c/4cdf1d2a816a93fa02f7b6b5492dc7f55af2a199
CVE ID: CVE-2025-23147 State: PUBLISHED Published: 2025-05-01T12:55:36.099Z Last Updated: 2025-11-03T19:42:41.362Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: i3c: Add NULL pointer check in i3c_master_queue_ibi() The I3C master driver may receive an IBI from a target device that has not been probed yet. In such cases, the master calls `i3c_master_queue_ibi()` to queue an IBI work task, leading to "Unable to handle kernel read from unreadable memory" and resulting in a kernel panic. Typical IBI handling flow: 1. The I3C master scans target devices and probes their respective drivers. 2. The target device driver calls `i3c_dev
: 1. The I3C master scans target devices and probes their respective drivers. 2. The target device driver calls `i3c_device_request_ibi()` to enable IBI and assigns `dev->ibi = ibi`. 3. The I3C master receives an IBI from the target device and calls `i3c_master_queue_ibi()` to queue the target device driver’s IBI handler task. However, since target device events are asynchronous to the I3C probe sequence, step 3 may occur before step 2, causing `dev->ibi` to be `NULL`, leading to a kernel panic. Add a NULL pointer check in `i3c_master_queue_ibi()` to prevent accessing an uninitialized `dev->ibi`, ensuring stability. Additional Analyst Notes: - CVE Program Container: References: - https://git
initialized `dev->ibi`, ensuring stability. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/1b54faa5f47fa7c642179744aeff03f0810dc62e - https://git.kernel.org/stable/c/09359e7c8751961937cb5fc50220969b0a4e1058 - https://git.kernel.org/stable/c/3ba402610843d7d15c7f3966a461deeeaff7fba4 - https://git.kernel.org/stable/c/d83b0c03ef8fbea2f03029a1cc1f5041f0e1d47f - https://git.kernel.org/stable/c/6871a676aa534e8f218279672e0445c725f81026 - https://git.kernel.org/stable/c/e6bba328578feb58c614c11868c259b40484c5fa - https://git.kernel.org/stable/c/fe4a4fc179b7898055555a11685915473588392e - https://git.kernel.org/stable/c/ff9d61db59bb27d16d3f872bff2620d508