deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-26689
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

ceph: prevent use-after-free in encode_cap_msg()

In fs/ceph/caps.c, in encode_cap_msg(), "use after free" error was
caught by KASAN at this line - 'ceph_buffer_get(arg->xattr_buf);'. This
implies before the refcount could be increment here, it was freed.

In same file, in "handle_cap_grant()" refcount is decremented by this
line - 'ceph_buffer_put(ci->i_xattrs.blob);'. It appears that a race
occurred and resource was freed by the latter line before the former
line could increment it.

encode_cap_msg() is called by __send_cap() and __send_cap() is called by
ceph_check_caps() after calling __prep_cap(). __prep_cap() is where
arg->xattr_buf is assigned to ci->i_xattrs.blob. This is the spot where
the refcount must be increased to prevent "use after free" error.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/70e329b[PII_REDACTED]58a6fe8c0de93c9fdd56c77; https://git.kernel.org/stable/c/7958c1bf5b03c6f1f58e724dbdec93f8f60b96fc; https://git.kernel.org/stable/c/8180d0c27b93a6eb60da1b08ea079e[PII_REDACTED]
CVE: CVE-2024-26690
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

net: stmmac: protect updates of 64-bit statistics counters

As explained by a comment in <linux/u64_stats_sync.h>, write side of struct
u64_stats_sync must ensure mutual exclusion, or one seqcount update could
be lost on 32-bit platforms, thus blocking readers forever. Such lockups
have been observed in real world after stmmac_xmit() on one CPU raced with
stmmac_napi_poll_tx() on another CPU.

To fix the issue without introducing a new lock, split the statics into
three parts:

1. fields updated only under the tx queue lock,
2. fields updated only during NAPI poll,
3. fields updated only from interrupt context,

Updates to fields in the first two groups are already serialized through
other locks. It is sufficient to split the existing struct u64_stats_sync
so that each group has its own.

Note that tx_set_ic_bit is updated from both contexts. Split this counter
so that each context gets its own, and calculate their sum to get the total
value in stmmac_get_ethtool_stats().

For the third group, multiple interrupts may be processed by different CPUs
at the same time, but interrupts on the same CPU will not nest. Move fields
from this group to a newly created per-cpu struct stmmac_pcpu_stats.
CVSS Score: 6.5 (MEDIUM)
References: https://git.kernel.org/stable/c/38cc3c6dcc09dc3a1800b5ec22aef643ca11eab8; https://git.kernel.org/stable/c/9680b2ab54ba8d72581100e8c[PII_REDACTED]1836e; https://git.kernel.org/stable/c/e6af0f082a4b87b99ad033003be2a904a1791b3f
CVE: CVE-2024-26691
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: arm64: Fix circular locking dependency

The rule inside kvm enforces that the vcpu->mutex is taken *inside*
kvm->lock. The rule is violated by the pkvm_create_hyp_vm() which acquires
the kvm->lock while already holding the vcpu->mutex lock from
kvm_vcpu_ioctl(). Avoid the circular locking dependency altogether by
protecting the hyp vm handle with the config_lock, much like we already
do for other forms of VM-scoped data.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/10c02aad111df02088d1a81792a709f6a7eca6cc; https://git.kernel.org/stable/c/3ab1c40a1e915e350d9181a4603af393141970cc; https://git.kernel.org/stable/c/3d16cebf01127f459dcfeb79ed77bd68b124c228
CVE: CVE-2024-26692
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

smb: Fix regression in writes when non-standard maximum write size negotiated

The conversion to netfs in the 6.3 kernel caused a regression when
maximum write size is set by the server to an unexpected value which is
not a multiple of 4096 (similarly if the user overrides the maximum
write size by setting mount parm "wsize", but sets it to a value that
is not a multiple of 4096).  When negotiated write size is not a
multiple of 4096 the netfs code can skip the end of the final
page when doing large sequential writes, causing data corruption.

This section of code is being rewritten/removed due to a large
netfs change, but until that point (ie for the 6.3 kernel until now)
we can not support non-standard maximum write sizes.

Add a warning if a user specifies a wsize on mount that is not
a multiple of 4096 (and round down), also add a change where we
round down the maximum write size if the server negotiates a value
that is not a multiple of 4096 (we also have to check to make sure that
we do not round it down to zero).
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-787
References: https://git.kernel.org/stable/c/4145ccff546ea868428b3e0fe6818c6261b574a9; https://git.kernel.org/stable/c/4860abb91f3d7fbaf8147d54782149bb1fc45892; https://git.kernel.org/stable/c/63c35afd50e28b49c5b75542045a8c42b696dab9
CVE: CVE-2024-26693
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: fix a crash when we run out of stations

A DoS tool that injects loads of authentication frames made our AP
crash. The iwl_mvm_is_dup() function couldn't find the per-queue
dup_data which was not allocated.

The root cause for that is that we ran out of stations in the firmware
and we didn't really add the station to the firmware, yet we didn't
return an error to mac80211.
Mac80211 was thinking that we have the station and because of that,
sta_info::uploaded was set to 1. This allowed
ieee80211_find_sta_by_ifaddr() to return a valid station object, but
that ieee80211_sta didn't have any iwl_mvm_sta object initialized and
that caused the crash mentioned earlier when we got Rx on that station.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/00f4eb31b8193f6070ce24df636883f9c104ca95; https://git.kernel.org/stable/c/b7198383ef2debe748118996f627452281cf27d7; https://git.kernel.org/stable/c/c12f0f4d4caf23b1bfdc2602b6b70d56bdcd6aa7
CVE: CVE-2024-26694
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: fix double-free bug

The storage for the TLV PC register data wasn't done like all
the other storage in the drv->fw area, which is cleared at the
end of deallocation. Therefore, the freeing must also be done
differently, explicitly NULL'ing it out after the free, since
otherwise there's a nasty double-free bug here if a file fails
to load after this has been parsed, and we get another free
later (e.g. because no other file exists.) Fix that by adding
the missing NULL assignment.
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/353d321f63f7dbfc9ef58498cc732c9fe886a596; https://git.kernel.org/stable/c/ab9d4bb9a1892439b3123fc52b19e32b9cdf80ad; https://git.kernel.org/stable/c/d24eb9a27bea8fe5237fa71be274391d9d51eff2
CVE: CVE-2024-26696
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix hang in nilfs_lookup_dirty_data_buffers()

Syzbot reported a hang issue in migrate_pages_batch() called by mbind()
and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2.

While migrate_pages_batch() locks a folio and waits for the writeback to
complete, the log writer thread that should bring the writeback to
completion picks up the folio being written back in
nilfs_lookup_dirty_data_buffers() that it calls for subsequent log
creation and was trying to lock the folio.  Thus causing a deadlock.

In the first place, it is unexpected that folios/pages in the middle of
writeback will be updated and become dirty.  Nilfs2 adds a checksum to
verify the validity of the log being written and uses it for recovery at
mount, so data changes during writeback are suppressed.  Since this is
broken, an unclean shutdown could potentially cause recovery to fail.

Investigation revealed that the root cause is that the wait for writeback
completion in nilfs_page_mkwrite() is conditional, and if the backing
device does not require stable writes, data may be modified without
waiting.

Fix these issues by making nilfs_page_mkwrite() wait for writeback to
finish regardless of the stable write requirement of the backing device.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/228742b2ddfb99dfd71e5a307e6088ab6836272e; https://git.kernel.org/stable/c/38296afe3c6ee07319e01bb249aa4bb47c07b534; https://git.kernel.org/stable/c/7e9b622bd0748cc104d66535b76d9b3535f9dc0f
CVE: CVE-2024-26697
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix data corruption in dsync block recovery for small block sizes

The helper function nilfs_recovery_copy_block() of
nilfs_recovery_dsync_blocks(), which recovers data from logs created by
data sync writes during a mount after an unclean shutdown, incorrectly
calculates the on-page offset when copying repair data to the file's page
cache.  In environments where the block size is smaller than the page
size, this flaw can cause data corruption and leak uninitialized memory
bytes during the recovery process.

Fix these issues by correcting this byte offset calculation on the page.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-787
References: https://git.kernel.org/stable/c/120f7fa2008e3bd8b7680b4ab5df942decf60fd5; https://git.kernel.org/stable/c/2000016bab499074e6248ea85aeea7dd762355d9; https://git.kernel.org/stable/c/2e1480538ef60bfee5473dfe02b1ecbaf1a4aa0d
CVE: CVE-2024-26698
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove

In commit ac[PII_REDACTED] ("hv_netvsc: Disable NAPI before closing the
VMBus channel"), napi_disable was getting called for all channels,
including all subchannels without confirming if they are enabled or not.

This caused hv_netvsc getting hung at napi_disable, when netvsc_probe()
has finished running but nvdev->subchan_work has not started yet.
netvsc_subchan_work() -> rndis_set_subchannel() has not created the
sub-channels and because of that netvsc_sc_open() is not running.
netvsc_remove() calls cancel_work_sync(&nvdev->subchan_work), for which
netvsc_subchan_work did not run.

netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI
cannot be scheduled. Then netvsc_sc_open() -> napi_enable will clear the
NAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the
opposite.

Now during netvsc_device_remove(), when napi_disable is called for those
subchannels, napi_disable gets stuck on infinite msleep.

This fix addresses this problem by ensuring that napi_disable() is not
getting called for non-enabled NAPI struct.
But netif_napi_del() is still necessary for these non-enabled NAPI struct
for cleanup purpose.

Call trace:
[  654.559417] task:modprobe        state:D stack:    0 pid: 2321 ppid:  1091 flags:0x00004002
[  654.568030] Call Trace:
[  654.571221]  <TASK>
[  654.573790]  __schedule+0x2d6/0x960
[  654.577733]  schedule+0x69/0xf0
[  654.581214]  schedule_timeout+0x87/0x140
[  654.585463]  ? __bpf_trace_tick_stop+0x20/0x20
[  654.590291]  msleep+0x2d/0x40
[  654.593625]  napi_disable+0x2b/0x80
[  654.597437]  netvsc_device_remove+0x8a/0x1f0 [hv_netvsc]
[  654.603935]  rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc]
[  654.611101]  ? do_wait_intr+0xb0/0xb0
[  654.615753]  netvsc_remove+0x7c/0x120 [hv_netvsc]
[  654.621675]  vmbus_remove+0x27/0x40 [hv_vmbus]
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/0e8875de9dad12805ff66e92cd5edea6a421f1cd; https://git.kernel.org/stable/c/22a77c0f5b[PII_REDACTED]df3288d067af51a2fd7b; https://git.kernel.org/stable/c/48a8ccccffbae10c91d31fc872db5c31aba07518
CVE: CVE-2024-26699
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix array-index-out-of-bounds in dcn35_clkmgr

[Why]
There is a potential memory access violation while
iterating through array of dcn35 clks.

[How]
Limit iteration per array size.
CVSS Score: 7.8 (HIGH)
CWE: CWE-129
References: https://git.kernel.org/stable/c/46806e59a[PII_REDACTED]0d216f54951a5b4d545bc; https://git.kernel.org/stable/c/ca400d8e0c1c9d79c08dfb6b7f966e26c8cae7fb; https://git.kernel.org/stable/c/46806e59a[PII_REDACTED]0d216f54951a5b4d545bc
CVE: CVE-2024-26702
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: magnetometer: rm3100: add boundary check for the value read from RM3100_REG_TMRC

Recently, we encounter kernel crash in function rm3100_common_probe
caused by out of bound access of array rm3100_samp_rates (because of
underlying hardware failures). Add boundary check to prevent out of
bound access.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-125
References: https://git.kernel.org/stable/c/176256ff8abff29335ecff905a09fb49e8dcf513; https://git.kernel.org/stable/c/1d8c67e94e9e977603473a543d4f322cf2c4aa01; https://git.kernel.org/stable/c/36a49290d7e6d554020057a409747a092b1d3b56
CVE: CVE-2024-26704
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: fix double-free of blocks due to wrong extents moved_len

In ext4_move_extents(), moved_len is only updated when all moves are
successfully executed, and only discards orig_inode and donor_inode
preallocations when moved_len is not zero. When the loop fails to exit
after successfully moving some extents, moved_len is not updated and
remains at 0, so it does not discard the preallocations.

If the moved extents overlap with the preallocated extents, the
overlapped extents are freed twice in ext4_mb_release_inode_pa() and
ext4_process_freed_data() (as described in commit 94d7c16cbbbd ("ext4:
Fix double-free of blocks with EXT4_IOC_MOVE_EXT")), and bb_free is
incremented twice. Hence when trim is executed, a zero-division bug is
triggered in mb_update_avg_fragment_size() because bb_free is not zero
and bb_fragments is zero.

Therefore, update move_len after each extent move to avoid the issue.
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/185eab30486ba3e7bf8b9c2e049c79a06ffd2bc1; https://git.kernel.org/stable/c/2883940b19c38d5884c[PII_REDACTED]acf4d7e148f; https://git.kernel.org/stable/c/55583e899a[PII_REDACTED]601364741a83e78d6ac4
CVE: CVE-2024-26705
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

parisc: BTLB: Fix crash when setting up BTLB at CPU bringup

When using hotplug and bringing up a 32-bit CPU, ask the firmware about the
BTLB information to set up the static (block) TLB entries.

For that write access to the static btlb_info struct is needed, but
since it is marked __ro_after_init the kernel segfaults with missing
write permissions.

Fix the crash by dropping the __ro_after_init annotation.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-862
References: https://git.kernel.org/stable/c/54944f45470af5965fb9c28cf962ec30f38a8f5b; https://git.kernel.org/stable/c/913b9d443a0180cf0de3548f1ab[PII_REDACTED]486; https://git.kernel.org/stable/c/aa52be55276614d33f22fbe7da36c40d6432d10b
CVE: CVE-2024-26706
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

parisc: Fix random data corruption from exception handler

The current exception handler implementation, which assists when accessing
user space memory, may exhibit random data corruption if the compiler decides
to use a different register than the specified register %r29 (defined in
ASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another
register, the fault handler will nevertheless store -EFAULT into %r29 and thus
trash whatever this register is used for.
Looking at the assembly I found that this happens sometimes in emulate_ldd().

To solve the issue, the easiest solution would be if it somehow is
possible to tell the fault handler which register is used to hold the error
code. Using %0 or %1 in the inline assembly is not posssible as it will show
up as e.g. %r29 (with the "%r" prefix), which the GNU assembler can not
convert to an integer.

This patch takes another, better and more flexible approach:
We extend the __ex_table (which is out of the execution path) by one 32-word.
In this word we tell the compiler to insert the assembler instruction
"or %r0,%r0,%reg", where %reg references the register which the compiler
choosed for the error return code.
In case of an access failure, the fault handler finds the __ex_table entry and
can examine the opcode. The used register is encoded in the lowest 5 bits, and
the fault handler can then store -EFAULT into this register.

Since we extend the __ex_table to 3 words we can't use the BUILDTIME_TABLE_SORT
config option any longer.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-787
References: https://git.kernel.org/stable/c/23027309b099ffc4efca5477009a11dccbdae592; https://git.kernel.org/stable/c/8b1d72395635af45410b66cc4c4ab37a12c4a831; https://git.kernel.org/stable/c/ce31d79aa1f13a2345791f84935281a2c194e003
CVE: CVE-2024-26707
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame()

Syzkaller reported [1] hitting a warning after failing to allocate
resources for skb in hsr_init_skb(). Since a WARN_ONCE() call will
not help much in this case, it might be prudent to switch to
netdev_warn_once(). At the very least it will suppress syzkaller
reports such as [1].

Just in case, use netdev_warn_once() in send_prp_supervision_frame()
for similar reasons.

[1]
HSR: Could not send supervision frame
WARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294
RIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294
...
Call Trace:
 <IRQ>
 hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382
 call_timer_fn+0x193/0x590 kernel/time/timer.c:1700
 expire_timers kernel/time/timer.c:1751 [inline]
 __run_timers+0x764/0xb20 kernel/time/timer.c:2022
 run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035
 __do_softirq+0x21a/0x8de kernel/softirq.c:553
 invoke_softirq kernel/softirq.c:427 [inline]
 __irq_exit_rcu kernel/softirq.c:632 [inline]
 irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644
 sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076
 </IRQ>
 <TASK>
 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649
...

This issue is also found in older kernels (at least up to 5.10).
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-770
References: https://git.kernel.org/stable/c/0d8011a878fdf96123bc0d6a12e2fe7ced5fddfb; https://git.kernel.org/stable/c/37e8c97e539015637cb920d3e6f1e404f707a06e; https://git.kernel.org/stable/c/547545e50c[PII_REDACTED]47ce490c68a1776b9b51
CVE: CVE-2024-26708
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

mptcp: really cope with fastopen race

Fastopen and PM-trigger subflow shutdown can race, as reported by
syzkaller.

In my first attempt to close such race, I missed the fact that
the subflow status can change again before the subflow_state_change
callback is invoked.

Address the issue additionally copying with all the states directly
reachable from TCP_FIN_WAIT1.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/337cebbd850f94147cee05252778f8f78b8c337f; https://git.kernel.org/stable/c/4bfe217e075d04e63c092df9d40c608e598c2ef2; https://git.kernel.org/stable/c/e158fb9679d15a2317ec13b4f6301bd26265df2f
CVE: CVE-2024-26709
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

powerpc/iommu: Fix the missing iommu_group_put() during platform domain attach

The function spapr_tce_platform_iommu_attach_dev() is missing to call
iommu_group_put() when the domain is already set. This refcount leak
shows up with BUG_ON() during DLPAR remove operation as:

  KernelBug: Kernel bug in state 'None': kernel BUG at arch/powerpc/platforms/pseries/iommu.c:100!
  Oops: Exception in kernel mode, sig: 5 [#1]
  LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=8192 NUMA pSeries
  <snip>
  Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_016) hv:phyp pSeries
  NIP:  c[PII_REDACTED]ff4d4 LR: c[PII_REDACTED]ff4cc CTR: [PII_REDACTED]
  REGS: c0000013aed5f840 TRAP: 0700   Tainted: G          I         (6.8.0-rc3-autotest-g99bd3cb0d12e)
  MSR:  [PII_REDACTED] <SF,EE,ME,IR,DR,RI,LE>  CR: 44002402  XER: 20040000
  CFAR: c000000000a0d170 IRQMASK: 0
  ...
  NIP iommu_reconfig_notifier+0x94/0x200
  LR  iommu_reconfig_notifier+0x8c/0x200
  Call Trace:
    iommu_reconfig_notifier+0x8c/0x200 (unreliable)
    notifier_call_chain+0xb8/0x19c
    blocking_notifier_call_chain+0x64/0x98
    of_reconfig_notify+0x44/0xdc
    of_detach_node+0x78/0xb0
    ofdt_write.part.0+0x86c/0xbb8
    proc_reg_write+0xf4/0x150
    vfs_write+0xf8/0x488
    ksys_write+0x84/0x140
    system_call_exception+0x138/0x330
    system_call_vectored_common+0x15c/0x2ec

The patch adds the missing iommu_group_put() call.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0846dd77c8349ec92ca0079c9c71d130f34cb192; https://git.kernel.org/stable/c/c90fdea9cac9eb419fc266e75d625cb60c8f7f6c; https://git.kernel.org/stable/c/0846dd77c8349ec92ca0079c9c71d130f34cb192
CVE: CVE-2024-26710
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

powerpc/kasan: Limit KASAN thread size increase to 32KB

KASAN is seen to increase stack usage, to the point that it was reported
to lead to stack overflow on some 32-bit machines (see link).

To avoid overflows the stack size was doubled for KASAN builds in
commit 3e8635fb2e07 ("powerpc/kasan: Force thread size increase with
KASAN").

However with a 32KB stack size to begin with, the doubling leads to a
64KB stack, which causes build errors:
  arch/powerpc/kernel/switch.S:249: Error: operand out of range (0x[PII_REDACTED]00fe50 is not between 0xffffffffffff8000 and 0x[PII_REDACTED]007fff)

Although the asm could be reworked, in practice a 32KB stack seems
sufficient even for KASAN builds - the additional usage seems to be in
the 2-3KB range for a 64-bit KASAN build.

So only increase the stack for KASAN if the stack size is < 32KB.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-770
References: https://git.kernel.org/stable/c/4cc31fa07445879a13750cb061bb8c2654975fcb; https://git.kernel.org/stable/c/b29b16bd836a838b7690f80e37f8376414c74cbe; https://git.kernel.org/stable/c/f1acb109505d983779bbb7e20a1ee6244d2b5736
CVE: CVE-2024-26711
Published: 2024-04-03
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: adc: ad4130: zero-initialize clock init data

The clk_init_data struct does not have all its members
initialized, causing issues when trying to expose the internal
clock on the CLK pin.

Fix this by zero-initializing the clk_init_data struct.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/02876e2df02f8b17a593d77a0a7879a8109b27e1; https://git.kernel.org/stable/c/0e0dab37750926d4fb0144edb1c1ea0612fea273; https://git.kernel.org/stable/c/a22b0a2be69a36511cb5b37d948b651ddf7debf3