deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-38524
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

rxrpc: Fix recv-recv race of completed call

If a call receives an event (such as incoming data), the call gets placed
on the socket's queue and a thread in recvmsg can be awakened to go and
process it.  Once the thread has picked up the call off of the queue,
further events will cause it to be requeued, and once the socket lock is
dropped (recvmsg uses call->user_mutex to allow the socket to be used in
parallel), a second thread can come in and its recvmsg can pop the call off
the socket queue again.

In such a case, the first thread will be receiving stuff from the call and
the second thread will be blocked on call->user_mutex.  The first thread
can, at this point, process both the event that it picked call for and the
event that the second thread picked the call for and may see the call
terminate - in which case the call will be "released", decoupling the call
from the user call ID assigned to it (RXRPC_USER_CALL_ID in the control
message).

The first thread will return okay, but then the second thread will wake up
holding the user_mutex and, if it sees that the call has been released by
the first thread, it will BUG thusly:

	kernel BUG at net/rxrpc/recvmsg.c:474!

Fix this by just dequeuing the call and ignoring it if it is seen to be
already released.  We can't tell userspace about it anyway as the user call
ID has become stale.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/6c75a97a32a5fa2060c3dd30207e63b6914b606d; https://git.kernel.org/stable/c/7692bde890061797f3dece0148d7859e85c55778; https://git.kernel.org/stable/c/839fe96c15209dc2255c064bb44b636efe04f032
CVE: CVE-2025-38525
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

rxrpc: Fix irq-disabled in local_bh_enable()

The rxrpc_assess_MTU_size() function calls down into the IP layer to find
out the MTU size for a route.  When accepting an incoming call, this is
called from rxrpc_new_incoming_call() which holds interrupts disabled
across the code that calls down to it.  Unfortunately, the IP layer uses
local_bh_enable() which, config dependent, throws a warning if IRQs are
enabled:

WARNING: CPU: 1 PID: 5544 at kernel/softirq.c:387 __local_bh_enable_ip+0x43/0xd0
...
RIP: 0010:__local_bh_enable_ip+0x43/0xd0
...
Call Trace:
 <TASK>
 rt_cache_route+0x7e/0xa0
 rt_set_nexthop.isra.0+0x3b3/0x3f0
 __mkroute_output+0x43a/0x460
 ip_route_output_key_hash+0xf7/0x140
 ip_route_output_flow+0x1b/0x90
 rxrpc_assess_MTU_size.isra.0+0x2a0/0x590
 rxrpc_new_incoming_peer+0x46/0x120
 rxrpc_alloc_incoming_call+0x1b1/0x400
 rxrpc_new_incoming_call+0x1da/0x5e0
 rxrpc_input_packet+0x827/0x900
 rxrpc_io_thread+0x403/0xb60
 kthread+0x2f7/0x310
 ret_from_fork+0x2a/0x230
 ret_from_fork_asm+0x1a/0x30
...
hardirqs last  enabled at (23): _raw_spin_unlock_irq+0x24/0x50
hardirqs last disabled at (24): _raw_read_lock_irq+0x17/0x70
softirqs last  enabled at (0): copy_process+0xc61/0x2730
softirqs last disabled at (25): rt_add_uncached_list+0x3c/0x90

Fix this by moving the call to rxrpc_assess_MTU_size() out of
rxrpc_init_peer() and further up the stack where it can be done without
interrupts disabled.

It shouldn't be a problem for rxrpc_new_incoming_call() to do it after the
locks are dropped as pmtud is going to be performed by the I/O thread - and
we're in the I/O thread at this point.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2029f21f10dedb88c0f86abffcf8d6c21dcf6040; https://git.kernel.org/stable/c/e4d2878369d590bf8455e3678a644e503172eafa
CVE: CVE-2025-38526
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

ice: add NULL check in eswitch lag check

The function ice_lag_is_switchdev_running() is being called from outside of
the LAG event handler code.  This results in the lag->upper_netdev being
NULL sometimes.  To avoid a NULL-pointer dereference, there needs to be a
check before it is dereferenced.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/245917d3c5ed7c6ae720302b64eac5c6f0c85177; https://git.kernel.org/stable/c/27591d926191e42b2332e4bad3bcd3a49def393b; https://git.kernel.org/stable/c/3ce58b01ada408b372f15b7c992ed0519840e3cf
CVE: CVE-2025-38527
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

smb: client: fix use-after-free in cifs_oplock_break

A race condition can occur in cifs_oplock_break() leading to a
use-after-free of the cinode structure when unmounting:

  cifs_oplock_break()
    _cifsFileInfo_put(cfile)
      cifsFileInfo_put_final()
        cifs_sb_deactive()
          [last ref, start releasing sb]
            kill_sb()
              kill_anon_super()
                generic_shutdown_super()
                  evict_inodes()
                    dispose_list()
                      evict()
                        destroy_inode()
                          call_rcu(&inode->i_rcu, i_callback)
    spin_lock(&cinode->open_file_lock)  <- OK
                            [later] i_callback()
                              cifs_free_inode()
                                kmem_cache_free(cinode)
    spin_unlock(&cinode->open_file_lock)  <- UAF
    cifs_done_oplock_break(cinode)       <- UAF

The issue occurs when umount has already released its reference to the
superblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), this
releases the last reference, triggering the immediate cleanup of all
inodes under RCU. However, cifs_oplock_break() continues to access the
cinode after this point, resulting in use-after-free.

Fix this by holding an extra reference to the superblock during the
entire oplock break operation. This ensures that the superblock and
its inodes remain valid until the oplock break completes.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/09bce2138a30ef10d8821c8c3f73a4ab7a5726bc; https://git.kernel.org/stable/c/0a4eec84d4d2c4085d4ed8630fd74e4b39033c1b; https://git.kernel.org/stable/c/2baaf5bbab2ac474c4f92c10fcb3310f824db995
CVE: CVE-2025-38528
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Reject %p% format string in bprintf-like helpers

static const char fmt[] = "%p%";
    bpf_trace_printk(fmt, sizeof(fmt));

The above BPF program isn't rejected and causes a kernel warning at
runtime:

    Please remove unsupported %\x00 in format string
    WARNING: CPU: 1 PID: 7244 at lib/vsprintf.c:2680 format_decode+0x49c/0x5d0

This happens because bpf_bprintf_prepare skips over the second %,
detected as punctuation, while processing %p. This patch fixes it by
not skipping over punctuation. %\x00 is then processed in the next
iteration and rejected.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1c5f5fd47bbda17cb885fe6f03730702cd53d3f8; https://git.kernel.org/stable/c/61d5fa45ed13e42af14c7e959baba9908b8ee6d4; https://git.kernel.org/stable/c/6952aeace93f8c9ea01849efecac24dd3152c9c9
CVE: CVE-2025-38529
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

comedi: aio_iiro_16: Fix bit shift out of bounds

When checking for a supported IRQ number, the following test is used:

	if ((1 << it->options[1]) & 0xdcfc) {

However, `it->options[i]` is an unchecked `int` value from userspace, so
the shift amount could be negative or out of bounds.  Fix the test by
requiring `it->options[1]` to be within bounds before proceeding with
the original test.  Valid `it->options[1]` values that select the IRQ
will be in the range [1,15]. The value 0 explicitly disables the use of
interrupts.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/43ddd82e6a91913cea1c078e782afd8de60c3a53; https://git.kernel.org/stable/c/5ac7c60439236fb691b8c7987390e2327bbf18fa; https://git.kernel.org/stable/c/66acb1586737a22dd7b78abc63213b1bcaa100e4
CVE: CVE-2025-38530
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

comedi: pcl812: Fix bit shift out of bounds

When checking for a supported IRQ number, the following test is used:

	if ((1 << it->options[1]) & board->irq_bits) {

However, `it->options[i]` is an unchecked `int` value from userspace, so
the shift amount could be negative or out of bounds.  Fix the test by
requiring `it->options[1]` to be within bounds before proceeding with
the original test.  Valid `it->options[1]` values that select the IRQ
will be in the range [1,15]. The value 0 explicitly disables the use of
interrupts.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/0489c30d080f07cc7f09d04de723d8c2ccdb61ef; https://git.kernel.org/stable/c/16c173abee315953fd17a279352fec4a1faee862; https://git.kernel.org/stable/c/29ef03e5b84431171d6b77b822985b54bc44b793
CVE: CVE-2025-38531
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: common: st_sensors: Fix use of uninitialize device structs

Throughout the various probe functions &indio_dev->dev is used before it
is initialized. This caused a kernel panic in st_sensors_power_enable()
when the call to devm_regulator_bulk_get_enable() fails and then calls
dev_err_probe() with the uninitialized device.

This seems to only cause a panic with dev_err_probe(), dev_err(),
dev_warn() and dev_info() don't seem to cause a panic, but are fixed
as well.

The issue is reported and traced here: [1]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/3297a9016a45144883ec990bd4bd5b1d79cafb46; https://git.kernel.org/stable/c/610615c9668037e3eca11132063b93b2d945af13; https://git.kernel.org/stable/c/9f92e93e257b33e73622640a9205f8642ec16ddd
CVE: CVE-2025-38533
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: libwx: fix the using of Rx buffer DMA

The wx_rx_buffer structure contained two DMA address fields: 'dma' and
'page_dma'. However, only 'page_dma' was actually initialized and used
to program the Rx descriptor. But 'dma' was uninitialized and used in
some paths.

This could lead to undefined behavior, including DMA errors or
use-after-free, if the uninitialized 'dma' was used. Althrough such
error has not yet occurred, it is worth fixing in the code.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/027701180a7bcb64c42eab291133ef0c87b5b6c5; https://git.kernel.org/stable/c/05c37b574997892a40a0e9b9b88a481566b2367d; https://git.kernel.org/stable/c/5fd77cc6bd9b368431a815a780e407b7781bcca0
CVE: CVE-2025-38534
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

netfs: Fix copy-to-cache so that it performs collection with ceph+fscache

The netfs copy-to-cache that is used by Ceph with local caching sets up a
new request to write data just read to the cache.  The request is started
and then left to look after itself whilst the app continues.  The request
gets notified by the backing fs upon completion of the async DIO write, but
then tries to wake up the app because NETFS_RREQ_OFFLOAD_COLLECTION isn't
set - but the app isn't waiting there, and so the request just hangs.

Fix this by setting NETFS_RREQ_OFFLOAD_COLLECTION which causes the
notification from the backing filesystem to put the collection onto a work
queue instead.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1ebe58cef84eab22b41b4d5e72c2051ebf00af50; https://git.kernel.org/stable/c/4c238e30774e3022a505fa54311273add7570f13
CVE: CVE-2025-38535
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

phy: tegra: xusb: Fix unbalanced regulator disable in UTMI PHY mode

When transitioning from USB_ROLE_DEVICE to USB_ROLE_NONE, the code
assumed that the regulator should be disabled. However, if the regulator
is marked as always-on, regulator_is_enabled() continues to return true,
leading to an incorrect attempt to disable a regulator which is not
enabled.

This can result in warnings such as:

[  250.155624] WARNING: CPU: 1 PID: 7326 at drivers/regulator/core.c:3004
_regulator_disable+0xe4/0x1a0
[  250.155652] unbalanced disables for VIN_SYS_5V0

To fix this, we move the regulator control logic into
tegra186_xusb_padctl_id_override() function since it's directly related
to the ID override state. The regulator is now only disabled when the role
transitions from USB_ROLE_HOST to USB_ROLE_NONE, by checking the VBUS_ID
register. This ensures that regulator enable/disable operations are
properly balanced and only occur when actually transitioning to/from host
mode.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/1bb85b5c2bd43b687c3d54eb6328917f90dd38fc; https://git.kernel.org/stable/c/5367cdeb75cb6c687ca468450bceb2602ab239d8; https://git.kernel.org/stable/c/cdcb0ffd6448f6be898956913a42bd08e59fb2ae
CVE: CVE-2025-38536
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: airoha: fix potential use-after-free in airoha_npu_get()

np->name was being used after calling of_node_put(np), which
releases the node and can lead to a use-after-free bug.
Previously, of_node_put(np) was called unconditionally after
of_find_device_by_node(np), which could result in a use-after-free if
pdev is NULL.

This patch moves of_node_put(np) after the error check to ensure
the node is only released after both the error and success cases
are handled appropriately, preventing potential resource issues.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/3cd582e7d[PII_REDACTED]ef0180405eb6224fa90a6; https://git.kernel.org/stable/c/df6bf96b41e547e350667bc4c143be53646d070d
CVE: CVE-2025-38537
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: phy: Don't register LEDs for genphy

If a PHY has no driver, the genphy driver is probed/removed directly in
phy_attach/detach. If the PHY's ofnode has an "leds" subnode, then the
LEDs will be (un)registered when probing/removing the genphy driver.
This could occur if the leds are for a non-generic driver that isn't
loaded for whatever reason. Synchronously removing the PHY device in
phy_detach leads to the following deadlock:

rtnl_lock()
ndo_close()
    ...
    phy_detach()
        phy_remove()
            phy_leds_unregister()
                led_classdev_unregister()
                    led_trigger_set()
                        netdev_trigger_deactivate()
                            unregister_netdevice_notifier()
                                rtnl_lock()

There is a corresponding deadlock on the open/register side of things
(and that one is reported by lockdep), but it requires a race while this
one is deterministic.

Generic PHYs do not support LEDs anyway, so don't bother registering
them.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/75e1b2079ef0653a2f7aa69be515d86b7faf1908; https://git.kernel.org/stable/c/ec158d05eaa91b2809cab65f8068290e3c05ebdd; https://git.kernel.org/stable/c/f0f2b992d8185a0366be951685e08643aae17d6d
CVE: CVE-2025-38538
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

dmaengine: nbpfaxi: Fix memory corruption in probe()

The nbpf->chan[] array is allocated earlier in the nbpf_probe() function
and it has "num_channels" elements.  These three loops iterate one
element farther than they should and corrupt memory.

The changes to the second loop are more involved.  In this case, we're
copying data from the irqbuf[] array into the nbpf->chan[] array.  If
the data in irqbuf[i] is the error IRQ then we skip it, so the iterators
are not in sync.  I added a check to ensure that we don't go beyond the
end of the irqbuf[] array.  I'm pretty sure this can't happen, but it
seemed harmless to add a check.

On the other hand, after the loop has ended there is a check to ensure
that the "chan" iterator is where we expect it to be.  In the original
code we went one element beyond the end of the array so the iterator
wasn't in the correct place and it would always return -EINVAL.  However,
now it will always be in the correct place.  I deleted the check since
we know the result.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/122160289adf8ebf15060f1cbf6265b55a914948; https://git.kernel.org/stable/c/188c6ba1dd925849c5d94885c8bbdeb0b3dcf510; https://git.kernel.org/stable/c/24861ef8b517a309a4225f2793be0cd8fa0bec9e
CVE: CVE-2025-38539
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

tracing: Add down_write(trace_event_sem) when adding trace event

When a module is loaded, it adds trace events defined by the module. It
may also need to modify the modules trace printk formats to replace enum
names with their values.

If two modules are loaded at the same time, the adding of the event to the
ftrace_events list can corrupt the walking of the list in the code that is
modifying the printk format strings and crash the kernel.

The addition of the event should take the trace_event_sem for write while
it adds the new event.

Also add a lockdep_assert_held() on that semaphore in
__trace_add_event_dirs() as it iterates the list.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/33e20747b47ddc03569b6bc27a2d6894c1428182; https://git.kernel.org/stable/c/6bc94f20a4c304997288f9a45278c9d0c06987d3; https://git.kernel.org/stable/c/70fecd519caad0c1741c3379d5348c9000a5b29d
CVE: CVE-2025-38540
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

HID: quirks: Add quirk for 2 Chicony Electronics HP 5MP Cameras

The Chicony Electronics HP 5MP Cameras (USB ID 04F2:B824 & 04F2:B82C)
report a HID sensor interface that is not actually implemented.
Attempting to access this non-functional sensor via iio_info causes
system hangs as runtime PM tries to wake up an unresponsive sensor.

Add these 2 devices to the HID ignore list since the sensor interface is
non-functional by design and should not be exposed to userspace.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1b297ab6f38ca60a4ca7298b297944ec6043b2f4; https://git.kernel.org/stable/c/2b0931eee48208c25bb77486946dea8e96aa6a36; https://git.kernel.org/stable/c/35f1a5360ac68d9629abbb3930a0a07901cba296
CVE: CVE-2025-38541
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7925: Fix null-ptr-deref in mt7925_thermal_init()

devm_kasprintf() returns NULL on error. Currently, mt7925_thermal_init()
does not check for this case, which results in a NULL pointer
dereference.

Add NULL check after devm_kasprintf() to prevent this issue.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/03ee8f73801a8f46d83dfc2bf73fb9ffa5a21602; https://git.kernel.org/stable/c/1bbdf4213711bb6dc365e7628430a63dd3280794; https://git.kernel.org/stable/c/2e99e9b34ece0b6d3e82cb757e9f60fa414da999
CVE: CVE-2025-38542
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: appletalk: Fix device refcount leak in atrtr_create()

When updating an existing route entry in atrtr_create(), the old device
reference was not being released before assigning the new device,
leading to a device refcount leak. Fix this by calling dev_put() to
release the old device reference before holding the new one.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/473f3eadfc73b0fb6d8dee5829d19a5772e387f7; https://git.kernel.org/stable/c/4a17370da6e476d3d275534e9e9cd2d02c57ca46; https://git.kernel.org/stable/c/64124cf0aab0dd1e18c0fb5ae66e45741e727f8b
CVE: CVE-2025-38543
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/tegra: nvdec: Fix dma_alloc_coherent error check

Check for NULL return value with dma_alloc_coherent, in line with
Robin's fix for vic.c in 'drm/tegra: vic: Fix DMA API misuse'.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2e0812eedccd0629d73c9d0b1184a5db055df1da; https://git.kernel.org/stable/c/44306a684cd1699b8562a54945ddc43e2abc9eab; https://git.kernel.org/stable/c/61b8d20962d00b7df117011c52f97cbb9c76a669
CVE: CVE-2025-38544
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

rxrpc: Fix bug due to prealloc collision

When userspace is using AF_RXRPC to provide a server, it has to preallocate
incoming calls and assign to them call IDs that will be used to thread
related recvmsg() and sendmsg() together.  The preallocated call IDs will
automatically be attached to calls as they come in until the pool is empty.

To the kernel, the call IDs are just arbitrary numbers, but userspace can
use the call ID to hold a pointer to prepared structs.  In any case, the
user isn't permitted to create two calls with the same call ID (call IDs
become available again when the call ends) and EBADSLT should result from
sendmsg() if an attempt is made to preallocate a call with an in-use call
ID.

However, the cleanup in the error handling will trigger both assertions in
rxrpc_cleanup_call() because the call isn't marked complete and isn't
marked as having been released.

Fix this by setting the call state in rxrpc_service_prealloc_one() and then
marking it as being released before calling the cleanup function.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-617
References: https://git.kernel.org/stable/c/432c5363cd6fe5a928bbc94524d28b05515684dd; https://git.kernel.org/stable/c/5385ad53793de2ab11e396bdcdaa65bb04b4dad6; https://git.kernel.org/stable/c/69e4186773c6445b258fb45b6e1df18df831ec45
CVE: CVE-2025-38545
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ethernet: ti: am65-cpsw-nuss: Fix skb size by accounting for skb_shared_info

While transitioning from netdev_alloc_ip_align() to build_skb(), memory
for the "skb_shared_info" member of an "skb" was not allocated. Fix this
by allocating "PAGE_SIZE" as the skb length, accounting for the packet
length, headroom and tailroom, thereby including the required memory space
for skb_shared_info.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/02c4d6c26f1f662da8885b299c224ca6628ad232; https://git.kernel.org/stable/c/7d6ca0c8c0caf9a13cae2de763bb1f2a9ea7eabb; https://git.kernel.org/stable/c/fc2fffa2facac15ce711e95f98f954426e025bc5
CVE: CVE-2025-38546
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

atm: clip: Fix memory leak of struct clip_vcc.

ioctl(ATMARP_MKIP) allocates struct clip_vcc and set it to
vcc->user_back.

The code assumes that vcc_destroy_socket() passes NULL skb
to vcc->push() when the socket is close()d, and then clip_push()
frees clip_vcc.

However, ioctl(ATMARPD_CTRL) sets NULL to vcc->push() in
atm_init_atmarp(), resulting in memory leak.

Let's serialise two ioctl() by lock_sock() and check vcc->push()
in atm_init_atmarp() to prevent memleak.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/0c17ff462d98c997d707ee5cf4e4a9b1b52b9d90; https://git.kernel.org/stable/c/1c075e88d5859a2c6b43b27e0e46fb281cef8039; https://git.kernel.org/stable/c/1fb9fb5a4b5cec2d56e26525ef8c519de858fa60
CVE: CVE-2025-38547
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: adc: axp20x_adc: Add missing sentinel to AXP717 ADC channel maps

The AXP717 ADC channel maps is missing a sentinel entry at the end. This
causes a KASAN warning.

Add the missing sentinel entry.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/086a76474121bf2351438e311376ec67b410b2ea; https://git.kernel.org/stable/c/0c0c01c88bb[PII_REDACTED]9d2001e67f0c613001f; https://git.kernel.org/stable/c/3281ddcea6429f7bc1fdb39d407752dd1371aba9