Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
ttps://git.kernel.org/stable/c/d0225f41ee70611ca88ccb22c8542ecdfa7faea8 - https://git.kernel.org/stable/c/ad8a9d38d30c691a77c456e72b78f7932d4f234d - https://git.kernel.org/stable/c/325bf7d57c4e2a341e381c5805e454fb69dd78c3 - https://git.kernel.org/stable/c/46288d12d1c30d08fbeffd05abc079f57a43a2d4 - https://git.kernel.org/stable/c/f5ad0819f902b4b33591791b92a0350fb3692a6b - https://git.kernel.org/stable/c/f1424c830d6ce840341aac33fe99c8ac45447ac1 - https://git.kernel.org/stable/c/f4bc3cdfe95115191e24592bbfc15f1d4a705a75 - https://git.kernel.org/stable/c/9dcf111dd3e7ed5fce82bb108e3a3fc001c07225
CVE ID: CVE-2025-39677 State: PUBLISHED Published: 2025-09-05T17:20:43.145Z Last Updated: 2025-09-29T05:57:13.148Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/sched: Fix backlog accounting in qdisc_dequeue_internal This issue applies for the following qdiscs: hhf, fq, fq_codel, and fq_pie, and occurs in their change handlers when adjusting to the new limit. The problem is the following in the values passed to the subsequent qdisc_tree_reduce_backlog call given a tbf parent: When the tbf parent runs out of tokens, skbs of these qdiscs will be placed in gso_skb. Their peek handlers are qdisc_peek_dequeued, which accounts f
of tokens, skbs of these qdiscs will be placed in gso_skb. Their peek handlers are qdisc_peek_dequeued, which accounts for both qlen and backlog. However, in the case of qdisc_dequeue_internal, ONLY qlen is accounted for when pulling from gso_skb. This means that these qdiscs are missing a qdisc_qstats_backlog_dec when dropping packets to satisfy the new limit in their change handlers. One can observe this issue with the following (with tc patched to support a limit of 0): export TARGET=fq tc qdisc del dev lo root tc qdisc add dev lo root handle 1: tbf rate 8bit burst 100b latency 1ms tc qdisc replace dev lo handle 3: parent 1:1 $TARGET limit 1000 echo ''; echo 'add child'; tc -s -d qdisc sh
latency 1ms tc qdisc replace dev lo handle 3: parent 1:1 $TARGET limit 1000 echo ''; echo 'add child'; tc -s -d qdisc show dev lo ping -I lo -f -c2 -s32 -W0.001 127.0.0.1 2>&1 >/dev/null echo ''; echo 'after ping'; tc -s -d qdisc show dev lo tc qdisc change dev lo handle 3: parent 1:1 $TARGET limit 0 echo ''; echo 'after limit drop'; tc -s -d qdisc show dev lo tc qdisc replace dev lo handle 2: parent 1:1 sfq echo ''; echo 'post graft'; tc -s -d qdisc show dev lo The second to last show command shows 0 packets but a positive number (74) of backlog bytes. The problem becomes clearer in the last show command, where qdisc_purge_queue triggers qdisc_tree_reduce_backlog with the positive backlog a
clearer in the last show command, where qdisc_purge_queue triggers qdisc_tree_reduce_backlog with the positive backlog and causes an underflow in the tbf parent's backlog (4096 Mb instead of 0). To fix this issue, the codepath for all clients of qdisc_dequeue_internal has been simplified: codel, pie, hhf, fq, fq_pie, and fq_codel. qdisc_dequeue_internal handles the backlog adjustments for all cases that do not directly use the dequeue handler. The old fq_codel_change limit adjustment loop accumulated the arguments to the subsequent qdisc_tree_reduce_backlog call through the cstats field. However, this is confusing and error prone as fq_codel_dequeue could also potentially mutate this field (
cstats field. However, this is confusing and error prone as fq_codel_dequeue could also potentially mutate this field (which qdisc_dequeue_internal calls in the non gso_skb case), so we have unified the code here with other qdiscs. References: - https://git.kernel.org/stable/c/a225f44d84b8900d679c5f5a9ea46fe9c0cc7802 - https://git.kernel.org/stable/c/52bf272636bda69587952b35ae97690b8dc89941
CVE ID: CVE-2025-39678 State: PUBLISHED Published: 2025-09-05T17:20:44.246Z Last Updated: 2025-10-29T13:19:05.807Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/hsmp: Ensure sock->metric_tbl_addr is non-NULL If metric table address is not allocated, accessing metrics_bin will result in a NULL pointer dereference, so add a check. References: - https://git.kernel.org/stable/c/782977c0d8ba432b6fd3d5d0d87016a523ec1c69 - https://git.kernel.org/stable/c/d47782d5c0cb87b9826041f34505580204ccf703 - https://git.kernel.org/stable/c/2c78fb287e1f430b929f2e49786518350d15605c
CVE ID: CVE-2025-39679 State: PUBLISHED Published: 2025-09-05T17:20:45.357Z Last Updated: 2025-09-29T05:57:15.710Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/nvif: Fix potential memory leak in nvif_vmm_ctor(). When the nvif_vmm_type is invalid, we will return error directly without freeing the args in nvif_vmm_ctor(), which leading a memory leak. Fix it by setting the ret -EINVAL and goto done. References: - https://git.kernel.org/stable/c/72553fe19317fe93cb8591c83095c446bc7fe292 - https://git.kernel.org/stable/c/cabcb52d76d3d42f16c344a96e098dd9d18602f8 - https://git.kernel.org/stable/c/7d9110e3b35d08832661da1a1
kernel.org/stable/c/cabcb52d76d3d42f16c344a96e098dd9d18602f8 - https://git.kernel.org/stable/c/7d9110e3b35d08832661da1a1fc2d24455981a04 - https://git.kernel.org/stable/c/bb8aeaa3191b617c6faf8ae937252e059673b7ea
CVE ID: CVE-2025-39680 State: PUBLISHED Published: 2025-09-05T17:20:46.456Z Last Updated: 2025-09-29T05:57:16.968Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: i2c: rtl9300: Fix out-of-bounds bug in rtl9300_i2c_smbus_xfer The data->block[0] variable comes from user. Without proper check, the variable may be very large to cause an out-of-bounds bug. Fix this bug by checking the value of data->block[0] first. 1. commit 39244cc75482 ("i2c: ismt: Fix an out-of-bounds bug in ismt_access()") 2. commit 92fbb6d1296f ("i2c: xgene-slimpro: Fix out-of-bounds bug in xgene_slimpro_i2c_xfer()") References: - https://git.kernel.org/stable/c
("i2c: xgene-slimpro: Fix out-of-bounds bug in xgene_slimpro_i2c_xfer()") References: - https://git.kernel.org/stable/c/071e43fcba5ddd9a7813e6cc0aa10299eae41b21 - https://git.kernel.org/stable/c/57f312b955938fc4663f430cb57a71f2414f601b
CVE ID: CVE-2025-39681 State: PUBLISHED Published: 2025-09-05T17:20:47.564Z Last Updated: 2025-11-03T17:42:12.739Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: x86/cpu/hygon: Add missing resctrl_cpu_detect() in bsp_init helper Since 923f3a2b48bd ("x86/resctrl: Query LLC monitoring properties once during boot") resctrl_cpu_detect() has been moved from common CPU initialization code to the vendor-specific BSP init helper, while Hygon didn't put that call in their code. This triggers a division by zero fault during early booting stage on our machines with X86_FEATURE_CQM* supported, where get_rdt_mon_resources() tries to calcula
ring early booting stage on our machines with X86_FEATURE_CQM* supported, where get_rdt_mon_resources() tries to calculate mon_l3_config with uninitialized boot_cpu_data.x86_cache_occ_scale. Add the missing resctrl_cpu_detect() in the Hygon BSP init helper. [ bp: Massage commit message. ] Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/62f12cde10118253348a7540e85606869bd69432 - https://git.kernel.org/stable/c/873f32201df8876bdb2563e3187e79149427cab4 - https://git.kernel.org/stable/c/fb81222c1559f89bfe3aa1010f6d112531d55353 - https://git.kernel.org/stable/c/7207923d8453ebfb35667c1736169f2dd796772e - https://git.kernel.org/stable/c/a9e5924daa954
https://git.kernel.org/stable/c/7207923d8453ebfb35667c1736169f2dd796772e - https://git.kernel.org/stable/c/a9e5924daa954c9f585c1ca00358afe71d6781c4 - https://git.kernel.org/stable/c/d23264c257a70dbe021b43b3bc2ee16134cd2c69 - https://git.kernel.org/stable/c/d8df126349dad855cdfedd6bbf315bad2e901c2f
CVE ID: CVE-2025-39682 State: PUBLISHED Published: 2025-09-05T17:20:48.657Z Last Updated: 2025-11-03T17:42:13.673Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tls: fix handling of zero-length records on the rx_list Each recvmsg() call must process either - only contiguous DATA records (any number of them) - one non-DATA record If the next record has different type than what has already been processed we break out of the main processing loop. If the record has already been decrypted (which may be the case for TLS 1.3 where we don't know type until decryption) we queue the pending record to the rx_list. Next recvmsg() will pic
r TLS 1.3 where we don't know type until decryption) we queue the pending record to the rx_list. Next recvmsg() will pick it up from there. Queuing the skb to rx_list after zero-copy decrypt is not possible, since in that case we decrypted directly to the user space buffer, and we don't have an skb to queue (darg.skb points to the ciphertext skb for access to metadata like length). Only data records are allowed zero-copy, and we break the processing loop after each non-data record. So we should never zero-copy and then find out that the record type has changed. The corner case we missed is when the initial record comes from rx_list, and it's zero length. Additional Analyst Notes: - CVE Progr
ase we missed is when the initial record comes from rx_list, and it's zero length. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/2902c3ebcca52ca845c03182000e8d71d3a5196f - https://git.kernel.org/stable/c/c09dd3773b5950e9cfb6c9b9a5f6e36d06c62677 - https://git.kernel.org/stable/c/3439c15ae91a517cf3c650ea15a8987699416ad9 - https://git.kernel.org/stable/c/29c0ce3c8cdb6dc5d61139c937f34cb888a6f42e - https://git.kernel.org/stable/c/62708b9452f8eb77513115b17c4f8d1a22ebf843
CVE ID: CVE-2025-39683 State: PUBLISHED Published: 2025-09-05T17:20:49.821Z Last Updated: 2025-11-03T17:42:15.575Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing: Limit access to parser->buffer when trace_get_user failed When the length of the string written to set_ftrace_filter exceeds FTRACE_BUFF_MAX, the following KASAN alarm will be triggered: BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0 Read of size 1 at addr ffff0000d00bd5ba by task ash/165 CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty Hardware name: linux,dummy-virt (DT) Call trace: show_stack+0x34/0x50 (C) dump_stack_lvl+0xa0/0x
6.0-g6bcdbd62bd56-dirty Hardware name: linux,dummy-virt (DT) Call trace: show_stack+0x34/0x50 (C) dump_stack_lvl+0xa0/0x158 print_address_description.constprop.0+0x88/0x398 print_report+0xb0/0x280 kasan_report+0xa4/0xf0 __asan_report_load1_noabort+0x20/0x30 strsep+0x18c/0x1b0 ftrace_process_regex.isra.0+0x100/0x2d8 ftrace_regex_release+0x484/0x618 __fput+0x364/0xa58 ____fput+0x28/0x40 task_work_run+0x154/0x278 do_notify_resume+0x1f0/0x220 el0_svc+0xec/0xf0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0 The reason is that trace_get_user will fail when processing a string longer than FTRACE_BUFF_MAX, but not set the end of parser->buffer to 0. Then an OOB access will be triggered in f
tring longer than FTRACE_BUFF_MAX, but not set the end of parser->buffer to 0. Then an OOB access will be triggered in ftrace_regex_release-> ftrace_process_regex->strsep->strpbrk. We can solve this problem by limiting access to parser->buffer when trace_get_user failed. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/b842ef39c2ad6156c13afdec25ecc6792a9b67b9 - https://git.kernel.org/stable/c/41b838420457802f21918df66764b6fbf829d330 - https://git.kernel.org/stable/c/418b448e1d7470da9d4d4797f71782595ee69c49 - https://git.kernel.org/stable/c/58ff8064cb4c7eddac4da1a59da039ead586950a - https://git.kernel.org/stable/c/d0c68045b8b0f3737ed7bd6b8c83b78
.org/stable/c/58ff8064cb4c7eddac4da1a59da039ead586950a - https://git.kernel.org/stable/c/d0c68045b8b0f3737ed7bd6b8c83b7887014adee - https://git.kernel.org/stable/c/3079517a5ba80901fe828a06998da64b9b8749be - https://git.kernel.org/stable/c/6a909ea83f226803ea0e718f6e88613df9234d58
CVE ID: CVE-2025-39684 State: PUBLISHED Published: 2025-09-05T17:20:50.827Z Last Updated: 2025-11-03T17:42:16.502Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: comedi: Fix use of uninitialized memory in do_insn_ioctl() and do_insnlist_ioctl() syzbot reports a KMSAN kernel-infoleak in `do_insn_ioctl()`. A kernel buffer is allocated to hold `insn->n` samples (each of which is an `unsigned int`). For some instruction types, `insn->n` samples are copied back to user-space, unless an error code is being returned. The problem is that not all the instruction handlers that need to return data to userspace fill in the whole `insn->n`
The problem is that not all the instruction handlers that need to return data to userspace fill in the whole `insn->n` samples, so that there is an information leak. There is a similar syzbot report for `do_insnlist_ioctl()`, although it does not have a reproducer for it at the time of writing. One culprit is `insn_rw_emulate_bits()` which is used as the handler for `INSN_READ` or `INSN_WRITE` instructions for subdevices that do not have a specific handler for that instruction, but do have an `INSN_BITS` handler. For `INSN_READ` it only fills in at most 1 sample, so if `insn->n` is greater than 1, the remaining `insn->n - 1` samples copied to userspace will be uninitialized kernel data. Ano
sn->n` is greater than 1, the remaining `insn->n - 1` samples copied to userspace will be uninitialized kernel data. Another culprit is `vm80xx_ai_insn_read()` in the "vm80xx" driver. It never returns an error, even if it fails to fill the buffer. Fix it in `do_insn_ioctl()` and `do_insnlist_ioctl()` by making sure that uninitialized parts of the allocated buffer are zeroed before handling each instruction. Thanks to Arnaud Lecomte for their fix to `do_insn_ioctl()`. That fix replaced the call to `kmalloc_array()` with `kcalloc()`, but it is not always necessary to clear the whole buffer. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/868a1b6
e whole buffer. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/868a1b68dcd9f2805bb86aa64862402f785d8c4a - https://git.kernel.org/stable/c/ff4a7c18799c7fe999fa56c5cf276e13866b8c1a - https://git.kernel.org/stable/c/d84f6e77ebe3359394df32ecd97e0d76a25283dc - https://git.kernel.org/stable/c/f3b0c9ec54736f3b8118f93a473d22e11ee65743 - https://git.kernel.org/stable/c/aecf0d557ddd95ce68193a5ee1dc4c87415ff08a - https://git.kernel.org/stable/c/3cd212e895ca2d58963fdc6422502b10dd3966bb
CVE ID: CVE-2025-39685 State: PUBLISHED Published: 2025-09-05T17:20:51.954Z Last Updated: 2025-11-03T17:42:17.438Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: comedi: pcl726: Prevent invalid irq number The reproducer passed in an irq number(0x80008000) that was too large, which triggered the oob. Added an interrupt number check to prevent users from passing in an irq number that was too large. If `it->options[1]` is 31, then `1 << it->options[1]` is still invalid because it shifts a 1-bit into the sign bit (which is UB in C). Possible solutions include reducing the upper bound on the `it->options[1]` value to 30 or lower, or
(which is UB in C). Possible solutions include reducing the upper bound on the `it->options[1]` value to 30 or lower, or using `1U << it->options[1]`. The old code would just not attempt to request the IRQ if the `options[1]` value were invalid. And it would still configure the device without interrupts even if the call to `request_irq` returned an error. So it would be better to combine this test with the test below. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/bab220b0bb5af652007e278e8e8357f952b0e1ea - https://git.kernel.org/stable/c/5a33d07c94ba91306093e823112a7aa9727549f6 - https://git.kernel.org/stable/c/0eb4ed2aa261dee228f1668dbfa6d87
.org/stable/c/5a33d07c94ba91306093e823112a7aa9727549f6 - https://git.kernel.org/stable/c/0eb4ed2aa261dee228f1668dbfa6d87353e8162d - https://git.kernel.org/stable/c/a3cfcd0c78c80ca7cd80372dc28f77d01be57bf6 - https://git.kernel.org/stable/c/d8992c9a01f81128f36acb7c5755530e21fcd059 - https://git.kernel.org/stable/c/96cb948408b3adb69df7e451ba7da9d21f814d00
CVE ID: CVE-2025-39686 State: PUBLISHED Published: 2025-09-05T17:20:53.071Z Last Updated: 2025-11-03T17:42:18.407Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: comedi: Make insn_rw_emulate_bits() do insn->n samples The `insn_rw_emulate_bits()` function is used as a default handler for `INSN_READ` instructions for subdevices that have a handler for `INSN_BITS` but not for `INSN_READ`. Similarly, it is used as a default handler for `INSN_WRITE` instructions for subdevices that have a handler for `INSN_BITS` but not for `INSN_WRITE`. It works by emulating the `INSN_READ` or `INSN_WRITE` instruction handling with a constructed `I
t not for `INSN_WRITE`. It works by emulating the `INSN_READ` or `INSN_WRITE` instruction handling with a constructed `INSN_BITS` instruction. However, `INSN_READ` and `INSN_WRITE` instructions are supposed to be able read or write multiple samples, indicated by the `insn->n` value, but `insn_rw_emulate_bits()` currently only handles a single sample. For `INSN_READ`, the comedi core will copy `insn->n` samples back to user-space. (That triggered KASAN kernel-infoleak errors when `insn->n` was greater than 1, but that is being fixed more generally elsewhere in the comedi core.) Make `insn_rw_emulate_bits()` either handle `insn->n` samples, or return an error, to conform to the general expecta
e.) Make `insn_rw_emulate_bits()` either handle `insn->n` samples, or return an error, to conform to the general expectation for `INSN_READ` and `INSN_WRITE` handlers. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/ab77e85bd3bc006ef40738f26f446a660813da44 - https://git.kernel.org/stable/c/ae8bc1f07bcb31b8636420e03d1f9c3df6219a2b - https://git.kernel.org/stable/c/842f307a1d115b24f2bcb2415c4e344f11f55930 - https://git.kernel.org/stable/c/92352ed2f9ac422181e381c2430c2d0dfb46faa0 - https://git.kernel.org/stable/c/dc0a2f142d655700db43de90cb6abf141b73d908 - https://git.kernel.org/stable/c/7afba9221f70d4cbce0f417c558879cba0eb5e66
CVE ID: CVE-2025-39687 State: PUBLISHED Published: 2025-09-05T17:20:54.154Z Last Updated: 2025-11-03T17:42:20.271Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iio: light: as73211: Ensure buffer holes are zeroed Given that the buffer is copied to a kfifo that ultimately user space can read, ensure we zero it. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/fd441fd972067f80861a0b66605c0febb0d038dd - https://git.kernel.org/stable/c/d8c5d87a431596e0e02bd7fe3bff952b002a03bb - https://git.kernel.org/stable/c/83f14c4ca1ad78fcfb3e0de07d6d8a0c59550fc2 - https://git.kernel.org/stable/c/
2b002a03bb - https://git.kernel.org/stable/c/83f14c4ca1ad78fcfb3e0de07d6d8a0c59550fc2 - https://git.kernel.org/stable/c/99b508340d0d1b9de0856c48c77898b14c0df7cf - https://git.kernel.org/stable/c/cce55ca4e7a221d5eb2c0b757a868eacd6344e4a - https://git.kernel.org/stable/c/8acd9a0eaa8c9a28e385c0a6a56bb821cb549771 - https://git.kernel.org/stable/c/433b99e922943efdfd62b9a8e3ad1604838181f2
CVE ID: CVE-2025-39688 State: PUBLISHED Published: 2025-04-18T07:01:35.177Z Last Updated: 2025-05-26T05:25:26.240Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nfsd: allow SC_STATUS_FREEABLE when searching via nfs4_lookup_stateid() The pynfs DELEG8 test fails when run against nfsd. It acquires a delegation and then lets the lease time out. It then tries to use the deleg stateid and expects to see NFS4ERR_DELEG_REVOKED, but it gets bad NFS4ERR_BAD_STATEID instead. When a delegation is revoked, it's initially marked with SC_STATUS_REVOKED, or SC_STATUS_ADMIN_REVOKED and later, it's marked with the SC_STATUS_FREEABLE flag, which
marked with SC_STATUS_REVOKED, or SC_STATUS_ADMIN_REVOKED and later, it's marked with the SC_STATUS_FREEABLE flag, which denotes that it is waiting for s FREE_STATEID call. nfs4_lookup_stateid() accepts a statusmask that includes the status flags that a found stateid is allowed to have. Currently, that mask never includes SC_STATUS_FREEABLE, which means that revoked delegations are (almost) never found. Add SC_STATUS_FREEABLE to the always-allowed status flags, and remove it from nfsd4_delegreturn() since it's now always implied. References: - https://git.kernel.org/stable/c/52e209203c35a4fbff8af23cd3613efe5df40102 - https://git.kernel.org/stable/c/dc6f3295905d7185e71091870119a8c11c3808cc -
c/52e209203c35a4fbff8af23cd3613efe5df40102 - https://git.kernel.org/stable/c/dc6f3295905d7185e71091870119a8c11c3808cc - https://git.kernel.org/stable/c/5bcb44e650bc4ec7eac23df90c5e011a77fa2beb - https://git.kernel.org/stable/c/d1bc15b147d35b4cb7ca99a9a7d79d41ca342c13
CVE ID: CVE-2025-39689 State: PUBLISHED Published: 2025-09-05T17:20:55.270Z Last Updated: 2025-11-03T17:42:22.147Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ftrace: Also allocate and copy hash for reading of filter files Currently the reader of set_ftrace_filter and set_ftrace_notrace just adds the pointer to the global tracer hash to its iterator. Unlike the writer that allocates a copy of the hash, the reader keeps the pointer to the filter hashes. This is problematic because this pointer is static across function calls that release the locks that can update the global tracer hashes. This can cause UAF and similar bugs.
ss function calls that release the locks that can update the global tracer hashes. This can cause UAF and similar bugs. Allocate and copy the hash for reading the filter files like it is done for the writers. This not only fixes UAF bugs, but also makes the code a bit simpler as it doesn't have to differentiate when to free the iterator's hash between writers and readers. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/12064e1880fc9202be75ff668205b1703d92f74f - https://git.kernel.org/stable/c/c4cd93811e038d19f961985735ef7bb128078dfb - https://git.kernel.org/stable/c/e0b6b223167e1edde5c82edf38e393c06eda1f13 - https://git.kernel.org/stable/c/a40
8078dfb - https://git.kernel.org/stable/c/e0b6b223167e1edde5c82edf38e393c06eda1f13 - https://git.kernel.org/stable/c/a40c69f4f1ed96acbcd62e9b5ff3a596f0a91309 - https://git.kernel.org/stable/c/3b114a3282ab1a12cb4618a8f45db5d7185e784a - https://git.kernel.org/stable/c/c591ba1acd081d4980713e47869dd1cc3d963d19 - https://git.kernel.org/stable/c/64db338140d2bad99a0a8c6a118dd60b3e1fb8cb - https://git.kernel.org/stable/c/bfb336cf97df7b37b2b2edec0f69773e06d11955
CVE ID: CVE-2025-39690 State: PUBLISHED Published: 2025-09-05T17:20:56.139Z Last Updated: 2025-09-29T05:57:28.533Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iio: accel: sca3300: fix uninitialized iio scan data Fix potential leak of uninitialized stack data to userspace by ensuring that the `channels` array is zeroed before use. References: - https://git.kernel.org/stable/c/c88c04adb8611e436e1e773fd5db3f8d7397d089 - https://git.kernel.org/stable/c/4e5b705cc6147f0b9173c6219079f41416bdd3c0