Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
ap[i] Use ixgbe_ls_map for supported and advertised linkmodes, and keep ixgbe_lp_map usage only for link partner (lp_advertised) mapping. References: - https://git.kernel.org/stable/c/682105ab63826fb7ca7c112b42b478d156fbb19f - https://git.kernel.org/stable/c/129c1cb8a081a02d99267cb51708f1326395f4e8 - https://git.kernel.org/stable/c/b7e5c3e3bfa9dc8af75ff6d8633ad7070e1985e4
CVE ID: CVE-2025-39923 State: PUBLISHED Published: 2025-10-01T08:07:11.469Z Last Updated: 2025-11-03T17:44:41.678Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees When we don't have a clock specified in the device tree, we have no way to ensure the BAM is on. This is often the case for remotely-controlled or remotely-powered BAM instances. In this case, we need to read num-channels from the DT to have all the necessary information to complete probing. However, at the moment invalid device trees without clock and without num-channels still continue probing, beca
probing. However, at the moment invalid device trees without clock and without num-channels still continue probing, because the error handling is missing return statements. The driver will then later try to read the number of channels from the registers. This is unsafe, because it relies on boot firmware and lucky timing to succeed. Unfortunately, the lack of proper error handling here has been abused for several Qualcomm SoCs upstream, causing early boot crashes in several situations [1, 2]. Avoid these early crashes by erroring out when any of the required DT properties are missing. Note that this will break some of the existing DTs upstream (mainly BAM instances related to the crypto engi
re missing. Note that this will break some of the existing DTs upstream (mainly BAM instances related to the crypto engine). However, clearly these DTs have never been tested properly, since the error in the kernel log was just ignored. It's safer to disable the crypto engine for these broken DTBs. [1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/ [2]: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linaro.org/ Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/2e257a6125c63350f00dc42b9674f20fd3cf4a9f - https://git.kernel.org/stable/c/1d98ba204d8a6db0d986c7f1aefaa0dcd1c007a2 - https://git.kernel.org/sta
9674f20fd3cf4a9f - https://git.kernel.org/stable/c/1d98ba204d8a6db0d986c7f1aefaa0dcd1c007a2 - https://git.kernel.org/stable/c/6ac1599d0e78036d9d08efc2f58c2d91f0a3ee4c - https://git.kernel.org/stable/c/555bd16351a35c79efb029a196975a5a27f7fbc4 - https://git.kernel.org/stable/c/ebf6c7c908e5999531c3517289598f187776124f - https://git.kernel.org/stable/c/1fc14731f0be4885e60702b9596d14d9a79cf053 - https://git.kernel.org/stable/c/0ff9df758af7022d749718fb6b8385cc5693acf3 - https://git.kernel.org/stable/c/5068b5254812433e841a40886e695633148d362d
CVE ID: CVE-2025-39924 State: PUBLISHED Published: 2025-10-01T08:07:12.300Z Last Updated: 2025-10-01T08:07:12.300Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: erofs: fix invalid algorithm for encoded extents The current algorithm sanity checks do not properly apply to new encoded extents. Unify the algorithm check with Z_EROFS_COMPRESSION(_RUNTIME)_MAX and ensure consistency with sbi->available_compr_algs. References: - https://git.kernel.org/stable/c/db5d7abd379a8dcf030be8f52f99cadf7e397ba8 - https://git.kernel.org/stable/c/131897c65e2b86cf14bec7379f44aa8fbb407526
CVE ID: CVE-2025-39925 State: PUBLISHED Published: 2025-10-01T08:07:13.123Z Last Updated: 2025-10-01T08:07:13.123Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: can: j1939: implement NETDEV_UNREGISTER notification handler syzbot is reporting unregister_netdevice: waiting for vcan0 to become free. Usage count = 2 problem, for j1939 protocol did not have NETDEV_UNREGISTER notification handler for undoing changes made by j1939_sk_bind(). Commit 25fe97cb7620 ("can: j1939: move j1939_priv_put() into sk_destruct callback") expects that a call to j1939_priv_put() can be unconditionally delayed until j1939_sk_sock_destruct() is called
llback") expects that a call to j1939_priv_put() can be unconditionally delayed until j1939_sk_sock_destruct() is called. But we need to call j1939_priv_put() against an extra ref held by j1939_sk_bind() call (as a part of undoing changes made by j1939_sk_bind()) as soon as NETDEV_UNREGISTER notification fires (i.e. before j1939_sk_sock_destruct() is called via j1939_sk_release()). Otherwise, the extra ref on "struct j1939_priv" held by j1939_sk_bind() call prevents "struct net_device" from dropping the usage count to 1; making it impossible for unregister_netdevice() to continue. [mkl: remove space in front of label] References: - https://git.kernel.org/stable/c/da9e8f429139928570407e8f9055
ntinue. [mkl: remove space in front of label] References: - https://git.kernel.org/stable/c/da9e8f429139928570407e8f90559b5d46c20262 - https://git.kernel.org/stable/c/7fcbe5b2c6a4b5407bf2241fdb71e0a390f6ab9a
CVE ID: CVE-2025-39926 State: PUBLISHED Published: 2025-10-01T08:07:13.883Z Last Updated: 2025-10-01T08:07:13.883Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: genetlink: fix genl_bind() invoking bind() after -EPERM Per family bind/unbind callbacks were introduced to allow families to track multicast group consumer presence, e.g. to start or stop producing events depending on listeners. However, in genl_bind() the bind() callback was invoked even if capability checks failed and ret was set to -EPERM. This means that callbacks could run on behalf of unauthorized callers while the syscall still returned failure to user space. F
ans that callbacks could run on behalf of unauthorized callers while the syscall still returned failure to user space. Fix this by only invoking bind() after "if (ret) break;" check i.e. after permission checks have succeeded. References: - https://git.kernel.org/stable/c/98c9d884047a3051c203708914a874dece3cbe54 - https://git.kernel.org/stable/c/8858c1e9405906c09589d7c336f04058ea198207 - https://git.kernel.org/stable/c/1dbfb0363224f6da56f6655d596dc5097308d6f5
CVE ID: CVE-2025-39927 State: PUBLISHED Published: 2025-10-01T08:07:14.595Z Last Updated: 2025-10-02T07:04:31.647Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ceph: fix race condition validating r_parent before applying state Add validation to ensure the cached parent directory inode matches the directory info in MDS replies. This prevents client-side race conditions where concurrent operations (e.g. rename) cause r_parent to become stale between request initiation and reply processing, which could lead to applying state changes to incorrect directory inodes. [ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex
applying state changes to incorrect directory inodes. [ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to move CEPH_CAP_PIN reference when r_parent is updated: When the parent directory lock is not held, req->r_parent can become stale and is updated to point to the correct inode. However, the associated CEPH_CAP_PIN reference was not being adjusted. The CEPH_CAP_PIN is a reference on an inode that is tracked for accounting purposes. Moving this pin is important to keep the accounting balanced. When the pin was not moved from the old parent to the new one, it created two problems: The reference on the old, stale parent was never released, causing a reference leak. A referenc
it created two problems: The reference on the old, stale parent was never released, causing a reference leak. A reference for the new parent was never acquired, creating the risk of a reference underflow later in ceph_mdsc_release_request(). This patch corrects the logic by releasing the pin from the old parent and acquiring it for the new parent when r_parent is switched. This ensures reference accounting stays balanced. ] References: - https://git.kernel.org/stable/c/db378e6f83ec705c6091c65d482d555edc2b0a72 - https://git.kernel.org/stable/c/2bfe45987eb346e299d9f763f9cd05f77011519f - https://git.kernel.org/stable/c/15f519e9f883b316d86e2bb6b767a023aafd9d83
CVE ID: CVE-2025-39928 State: PUBLISHED Published: 2025-10-01T08:07:15.530Z Last Updated: 2025-10-01T08:07:15.530Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: i2c: rtl9300: ensure data length is within supported range Add an explicit check for the xfer length to 'rtl9300_i2c_config_xfer' to ensure the data length isn't within the supported range. In particular a data length of 0 is not supported by the hardware and causes unintended or destructive behaviour. This limitation becomes obvious when looking at the register documentation [1]. 4 bits are reserved for DATA_WIDTH and the value of these 4 bits is used as N + 1, allowi
he register documentation [1]. 4 bits are reserved for DATA_WIDTH and the value of these 4 bits is used as N + 1, allowing a data length range of 1 <= len <= 16. Affected by this is the SMBus Quick Operation which works with a data length of 0. Passing 0 as the length causes an underflow of the value due to: (len - 1) & 0xf and effectively specifying a transfer length of 16 via the registers. This causes a 16-byte write operation instead of a Quick Write. For example, on SFP modules without write-protected EEPROM this soft-bricks them by overwriting some initial bytes. For completeness, also add a quirk for the zero length. [1] https://svanheule.net/realtek/longan/register/i2c_mst1_ctrl2 Ref
completeness, also add a quirk for the zero length. [1] https://svanheule.net/realtek/longan/register/i2c_mst1_ctrl2 References: - https://git.kernel.org/stable/c/c91382328fc89f73144d5582f2d8f1dd3e41c8f7 - https://git.kernel.org/stable/c/06418cb5a1a542a003fdb4ad8e76ea542d57cfba
CVE ID: CVE-2025-39929 State: PUBLISHED Published: 2025-10-04T07:30:55.153Z Last Updated: 2025-10-04T07:30:55.153Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: smb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path During tests of another unrelated patch I was able to trigger this error: Objects remaining on __kmem_cache_shutdown() References: - https://git.kernel.org/stable/c/3d7c075c878ac844e33c43e506c2fa27ac7e9689 - https://git.kernel.org/stable/c/e7b7a93879558e77d950f1ff9a6f3daa385b33df - https://git.kernel.org/stable/c/922338efaad63cfe30d459dfc59f9d69ff93ded4 - https://git.kernel.org/stable/c/0991418bf98f
https://git.kernel.org/stable/c/922338efaad63cfe30d459dfc59f9d69ff93ded4 - https://git.kernel.org/stable/c/0991418bf98f191d0c320bd25245fcffa1998c7e - https://git.kernel.org/stable/c/daac51c7032036a0ca5f1aa419ad1b0471d1c6e0
CVE ID: CVE-2025-39930 State: PUBLISHED Published: 2025-04-18T07:01:38.576Z Last Updated: 2025-05-26T05:25:32.730Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: simple-card-utils: Don't use __free(device_node) at graph_util_parse_dai() commit 419d1918105e ("ASoC: simple-card-utils: use __free(device_node) for device node") uses __free(device_node) for dlc->of_node, but we need to keep it while driver is in use. Don't use __free(device_node) in graph_util_parse_dai(). References: - https://git.kernel.org/stable/c/232a32e8a7e9be8a2ee238df9b5304eed2f4e195 - https://git.kernel.org/stable/c/de74ec718e0788e1998eb7289ad07970e27
/stable/c/232a32e8a7e9be8a2ee238df9b5304eed2f4e195 - https://git.kernel.org/stable/c/de74ec718e0788e1998eb7289ad07970e27cae27
CVE ID: CVE-2025-39931 State: PUBLISHED Published: 2025-10-04T07:30:55.964Z Last Updated: 2025-10-04T07:30:55.964Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Set merge to zero early in af_alg_sendmsg If an error causes af_alg_sendmsg to abort, ctx->merge may contain a garbage value from the previous loop. This may then trigger a crash on the next entry into af_alg_sendmsg when it attempts to do a merge that can't be done. Fix this by setting ctx->merge to zero near the start of the loop. References: - https://git.kernel.org/stable/c/6241b9e2809b12da9130894cf5beddf088dc1b8a - https://git.kernel.org/stable/c/
eferences: - https://git.kernel.org/stable/c/6241b9e2809b12da9130894cf5beddf088dc1b8a - https://git.kernel.org/stable/c/2374c11189ef704a3e4863646369f1b8e6a27d71 - https://git.kernel.org/stable/c/24c1106504c625fabd3b7229611af617b4c27ac7 - https://git.kernel.org/stable/c/045ee26aa3920a47ec46d7fcb302420bf01fd753 - https://git.kernel.org/stable/c/9574b2330dbd2b5459b74d3b5e9619d39299fc6f
CVE ID: CVE-2025-39932 State: PUBLISHED Published: 2025-10-04T07:30:56.726Z Last Updated: 2025-10-04T07:30:56.726Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: smb: client: let smbd_destroy() call disable_work_sync(&info->post_send_credits_work) In smbd_destroy() we may destroy the memory so we better wait until post_send_credits_work is no longer pending and will never be started again. I actually just hit the case using rxe: WARNING: CPU: 0 PID: 138 at drivers/infiniband/sw/rxe/rxe_verbs.c:1032 rxe_post_recv+0x1ee/0x480 [rdma_rxe] ... [ 5305.686979] [ T138] smbd_post_recv+0x445/0xc10 [cifs] [ 5305.687135] [ T138] ? srso_ali
cv+0x1ee/0x480 [rdma_rxe] ... [ 5305.686979] [ T138] smbd_post_recv+0x445/0xc10 [cifs] [ 5305.687135] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687149] [ T138] ? __kasan_check_write+0x14/0x30 [ 5305.687185] [ T138] ? __pfx_smbd_post_recv+0x10/0x10 [cifs] [ 5305.687329] [ T138] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 5305.687356] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687368] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687378] [ T138] ? _raw_spin_unlock_irqrestore+0x11/0x60 [ 5305.687389] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687399] [ T138] ? get_receive_buffer+0x168/0x210 [cifs] [ 5305.687555] [ T138] smbd_post_send_credits+0x382/0x4b0 [ci
05.687399] [ T138] ? get_receive_buffer+0x168/0x210 [cifs] [ 5305.687555] [ T138] smbd_post_send_credits+0x382/0x4b0 [cifs] [ 5305.687701] [ T138] ? __pfx_smbd_post_send_credits+0x10/0x10 [cifs] [ 5305.687855] [ T138] ? __pfx___schedule+0x10/0x10 [ 5305.687865] [ T138] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 5305.687875] [ T138] ? queue_delayed_work_on+0x8e/0xa0 [ 5305.687889] [ T138] process_one_work+0x629/0xf80 [ 5305.687908] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687917] [ T138] ? __kasan_check_write+0x14/0x30 [ 5305.687933] [ T138] worker_thread+0x87f/0x1570 ... It means rxe_post_recv was called after rdma_destroy_qp(). This happened because put_receive_buffer() was triggere
0 ... It means rxe_post_recv was called after rdma_destroy_qp(). This happened because put_receive_buffer() was triggered by ib_drain_qp() and called: queue_work(info->workqueue, &info->post_send_credits_work); References: - https://git.kernel.org/stable/c/6ae90a2baf923e85eb037b636aa641250bf4220f - https://git.kernel.org/stable/c/3fabb1236f2e3ad78d531be0a4ad9f4a4ccdda87 - https://git.kernel.org/stable/c/d9dcbbcf9145b68aa85c40947311a6907277e097
CVE ID: CVE-2025-39933 State: PUBLISHED Published: 2025-10-04T07:30:57.496Z Last Updated: 2025-10-04T07:30:57.496Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: smb: client: let recv_done verify data_offset, data_length and remaining_data_length This is inspired by the related server fixes. References: - https://git.kernel.org/stable/c/581fb78e0388b78911b0c920e4073737090c8b5f - https://git.kernel.org/stable/c/f57e53ea252363234f86674db475839e5b87102e
CVE ID: CVE-2025-39934 State: PUBLISHED Published: 2025-10-04T07:30:58.284Z Last Updated: 2025-10-04T07:37:00.467Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm: bridge: anx7625: Fix NULL pointer dereference with early IRQ If the interrupt occurs before resource initialization is complete, the interrupt handler/worker may access uninitialized data such as the I2C tcpc_client device, potentially leading to NULL pointer dereference. References: - https://git.kernel.org/stable/c/51a501e990a353a4f15da6bab295b28e5d118f64 - https://git.kernel.org/stable/c/f9a089d0a6d537d0f2061c8a37a7de535ce0310e - https://git.kernel.org/stable/c
28e5d118f64 - https://git.kernel.org/stable/c/f9a089d0a6d537d0f2061c8a37a7de535ce0310e - https://git.kernel.org/stable/c/15a77e1ab0a994d69b471c76b8d01117128dda26 - https://git.kernel.org/stable/c/0da73f7827691a5e2265b110d5fe12f29535ec92 - https://git.kernel.org/stable/c/1a7ea294d57fb61485d11b3f2241d631d73025cb - https://git.kernel.org/stable/c/a10f910c77f280327b481e77eab909934ec508f0
CVE ID: CVE-2025-39935 State: PUBLISHED Published: 2025-10-04T07:30:59.102Z Last Updated: 2025-10-04T07:30:59.102Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: codec: sma1307: Fix memory corruption in sma1307_setting_loaded() The sma1307->set.header_size is how many integers are in the header (there are 8 of them) but instead of allocating space of 8 integers we allocate 8 bytes. This leads to memory corruption when we copy data it on the next line: memcpy(sma1307->set.header, data, sma1307->set.header_size * sizeof(int)); Also since we're immediately copying over the memory in ->set.header, there is no need to zero it
_size * sizeof(int)); Also since we're immediately copying over the memory in ->set.header, there is no need to zero it in the allocator. Use devm_kmalloc_array() to allocate the memory instead. References: - https://git.kernel.org/stable/c/cd59ca8f75dbb42a67fcae975c766114644e36c4 - https://git.kernel.org/stable/c/78338108b5a856dc98223a335f147846a8a18c51
CVE ID: CVE-2025-39936 State: PUBLISHED Published: 2025-10-04T07:30:59.857Z Last Updated: 2025-10-04T07:30:59.857Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Always pass in an error pointer to __sev_platform_shutdown_locked() When 9770b428b1a2 ("crypto: ccp - Move dev_info/err messages for SEV/SNP init and shutdown") moved the error messages dumping so that they don't need to be issued by the callers, it missed the case where __sev_firmware_shutdown() calls __sev_platform_shutdown_locked() with a NULL argument which leads to a NULL ptr deref on the shutdown path, during suspend to disk: #PF: supervisor read ac
th a NULL argument which leads to a NULL ptr deref on the shutdown path, during suspend to disk: #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 983 Comm: hib.sh Not tainted 6.17.0-rc4+ #1 PREEMPT(voluntary) Hardware name: Supermicro Super Server/H12SSL-i, BIOS 2.5 09/08/2022 RIP: 0010:__sev_platform_shutdown_locked.cold+0x0/0x21 [ccp] That rIP is: 00000000000006fd <__sev_platform_shutdown_locked.cold>: 6fd: 8b 13 mov (%rbx),%edx 6ff: 48 8b 7d 00 mov 0x0(%rbp),%rdi 703: 89 c1 mov %eax,%ecx Code: 74 05 31 ff 41 89 3f 49 8b 3e 89 ea 48 c7 c6 a0 8e 54 a0 41 bf 92 ff ff ff e8 e5 2e 09 e1 c6 05 2a
1 mov %eax,%ecx Code: 74 05 31 ff 41 89 3f 49 8b 3e 89 ea 48 c7 c6 a0 8e 54 a0 41 bf 92 ff ff ff e8 e5 2e 09 e1 c6 05 2a d4 38 00 01 e9 26 af ff ff <8b> 13 48 8b 7d 00 89 c1 48 c7 c6 18 90 54 a0 89 44 24 04 e8 c1 2e RSP: 0018:ffffc90005467d00 EFLAGS: 00010282 RAX: 00000000ffffff92 RBX: 0000000000000000 RCX: 0000000000000000 ^^^^^^^^^^^^^^^^ and %rbx is nice and clean. Call Trace: <TASK> __sev_firmware_shutdown.isra.0 sev_dev_destroy psp_dev_destroy sp_destroy pci_device_shutdown device_shutdown kernel_power_off hibernate.cold state_store kernfs_fop_write_iter vfs_write ksys_write do_syscall_64 entry_SYSCALL_64_after_hwframe Pass in a pointer to the function-local error var in the caller. Wit
_write do_syscall_64 entry_SYSCALL_64_after_hwframe Pass in a pointer to the function-local error var in the caller. With that addressed, suspending the ccp shows the error properly at least: ccp 0000:47:00.1: sev command 0x2 timed out, disabling PSP ccp 0000:47:00.1: SEV: failed to SHUTDOWN error 0x0, rc -110 SEV-SNP: Leaking PFN range 0x146800-0x146a00 SEV-SNP: PFN 0x146800 unassigned, dumping non-zero entries in 2M PFN region: [0x146800 - 0x146a00] ... ccp 0000:47:00.1: SEV-SNP firmware shutdown failed, rc -16, error 0x0 ACPI: PM: Preparing to enter system sleep state S5 kvm: exiting hardware virtualization reboot: Power down Btw, this driver is crying to be cleaned up to pass in a proper
kvm: exiting hardware virtualization reboot: Power down Btw, this driver is crying to be cleaned up to pass in a proper I/O struct which can be used to store information between the different functions, otherwise stuff like that will happen in the future again. References: - https://git.kernel.org/stable/c/bc509293c9d4f4f74e776f4a0bbb61f63c041938 - https://git.kernel.org/stable/c/46834d90a9a13549264b9581067d8f746b4b36cc
CVE ID: CVE-2025-39937 State: PUBLISHED Published: 2025-10-04T07:31:00.879Z Last Updated: 2025-10-04T07:37:01.924Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer Since commit 7d5e9737efda ("net: rfkill: gpio: get the name and type from device property") rfkill_find_type() gets called with the possibly uninitialized "const char *type_name;" local variable. On x86 systems when rfkill-gpio binds to a "BCM4752" or "LNV4752" acpi_device, the rfkill->type is set based on the ACPI acpi_device_id: rfkill->type = (unsigned)id->driver_data; and there is no "type" p
rfkill->type is set based on the ACPI acpi_device_id: rfkill->type = (unsigned)id->driver_data; and there is no "type" property so device_property_read_string() will fail and leave type_name uninitialized, leading to a potential crash. rfkill_find_type() does accept a NULL pointer, fix the potential crash by initializing type_name to NULL. Note likely sofar this has not been caught because: 1. Not many x86 machines actually have a "BCM4752"/"LNV4752" acpi_device 2. The stack happened to contain NULL where type_name is stored References: - https://git.kernel.org/stable/c/184f608a68f96794e8fe58cd5535014d53622cde - https://git.kernel.org/stable/c/8793e7a8e1b60131a825457174ed6398111daeb7 - https
f608a68f96794e8fe58cd5535014d53622cde - https://git.kernel.org/stable/c/8793e7a8e1b60131a825457174ed6398111daeb7 - https://git.kernel.org/stable/c/ada2282259243387e6b6e89239aeb4897e62f051 - https://git.kernel.org/stable/c/47ade5f9d70b23a119ec20b1c6504864b2543a79 - https://git.kernel.org/stable/c/689aee35ce671aab752f159e5c8e66d7685e6887 - https://git.kernel.org/stable/c/21ba85d9d508422ca9e6698463ff9357c928c22d - https://git.kernel.org/stable/c/21a39b958b4bcf44f7674bfbbe1bbb8cad0d842d - https://git.kernel.org/stable/c/b6f56a44e4c1014b08859dcf04ed246500e310e5
CVE ID: CVE-2025-39938 State: PUBLISHED Published: 2025-10-04T07:31:01.736Z Last Updated: 2025-10-04T07:31:01.736Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: q6apm-lpass-dais: Fix NULL pointer dereference if source graph failed If earlier opening of source graph fails (e.g. ADSP rejects due to incorrect audioreach topology), the graph is closed and "dai_data->graph[dai->id]" is assigned NULL. Preparing the DAI for sink graph continues though and next call to q6apm_lpass_dai_prepare() receives dai_data->graph[dai->id]=NULL leading to NULL pointer exception: qcom-apm gprsvc:service:2:1: Error (1) Processing 0x0100