deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-49778
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

arm64/mm: fix incorrect file_map_count for non-leaf pmd/pud

The page table check trigger BUG_ON() unexpectedly when collapse hugepage:

 ------------[ cut here ]------------
 kernel BUG at mm/page_table_check.c:82!
 Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
 Dumping ftrace buffer:
    (ftrace buffer empty)
 Modules linked in:
 CPU: 6 PID: 68 Comm: khugepaged Not tainted 6.1.0-rc3+ #750
 Hardware name: linux,dummy-virt (DT)
 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : page_table_check_clear.isra.0+0x258/0x3f0
 lr : page_table_check_clear.isra.0+0x240/0x3f0
[...]
 Call trace:
  page_table_check_clear.isra.0+0x258/0x3f0
  __page_table_check_pmd_clear+0xbc/0x108
  pmdp_collapse_flush+0xb0/0x160
  collapse_huge_page+0xa08/0x1080
  hpage_collapse_scan_pmd+0xf30/0x1590
  khugepaged_scan_mm_slot.constprop.0+0x52c/0xac8
  khugepaged+0x338/0x518
  kthread+0x278/0x2f8
  ret_from_fork+0x10/0x20
[...]

Since pmd_user_accessible_page() doesn't check if a pmd is leaf, it
decrease file_map_count for a non-leaf pmd comes from collapse_huge_page().
and so trigger BUG_ON() unexpectedly.

Fix this problem by using pmd_leaf() insteal of pmd_present() in
pmd_user_accessible_page(). Moreover, use pud_leaf() for
pud_user_accessible_page() too.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-617
References: https://git.kernel.org/stable/c/2d458046df634088611d44fd77f45465e833ef78; https://git.kernel.org/stable/c/5b47348fc0b18a78c96f8474cc90b7525ad1bbfe
CVE: CVE-2022-49779
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

kprobes: Skip clearing aggrprobe's post_handler in kprobe-on-ftrace case

In __unregister_kprobe_top(), if the currently unregistered probe has
post_handler but other child probes of the aggrprobe do not have
post_handler, the post_handler of the aggrprobe is cleared. If this is
a ftrace-based probe, there is a problem. In later calls to
disarm_kprobe(), we will use kprobe_ftrace_ops because post_handler is
NULL. But we're armed with kprobe_ipmodify_ops. This triggers a WARN in
__disarm_kprobe_ftrace() and may even cause use-after-free:

  Failed to disarm kprobe-ftrace at kernel_clone+0x0/0x3c0 (error -2)
  WARNING: CPU: 5 PID: 137 at kernel/kprobes.c:1135 __disarm_kprobe_ftrace.isra.21+0xcf/0xe0
  Modules linked in: testKprobe_007(-)
  CPU: 5 PID: 137 Comm: rmmod Not tainted 6.1.0-rc4-dirty #18
  [...]
  Call Trace:
   <TASK>
   __disable_kprobe+0xcd/0xe0
   __unregister_kprobe_top+0x12/0x150
   ? mutex_lock+0xe/0x30
   unregister_kprobes.part.23+0x31/0xa0
   unregister_kprobe+0x32/0x40
   __x64_sys_delete_module+0x15e/0x260
   ? do_user_addr_fault+0x2cd/0x6b0
   do_syscall_64+0x3a/0x90
   entry_SYSCALL_64_after_hwframe+0x63/0xcd
   [...]

For the kprobe-on-ftrace case, we keep the post_handler setting to
identify this aggrprobe armed with kprobe_ipmodify_ops. This way we
can disarm it correctly.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/55788ebbe8b365b4375bd56b4ba7db79d393a370; https://git.kernel.org/stable/c/5dd7caf0bdc5d0bae7cf9776b4d739fb09bd5ebb; https://git.kernel.org/stable/c/7b0007b28dd970176f2e297c06ae63eea2447127
CVE: CVE-2022-49780
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: target: tcm_loop: Fix possible name leak in tcm_loop_setup_hba_bus()

If device_register() fails in tcm_loop_setup_hba_bus(), the name allocated
by dev_set_name() need be freed. As comment of device_register() says, it
should use put_device() to give up the reference in the error path. So fix
this by calling put_device(), then the name can be freed in kobject_cleanup().
The 'tl_hba' will be freed in tcm_loop_release_adapter(), so it don't need
goto error label in this case.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/28f7ff5e7559d226e63c7c5de74eb075a83d8c53; https://git.kernel.org/stable/c/41a6b8b527a5957fab41c3c05e25ad125268e2e9; https://git.kernel.org/stable/c/75205f1b47a88c3fac4f30bd7567e89b2887c7fd
CVE: CVE-2022-49781
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

perf/x86/amd: Fix crash due to race between amd_pmu_enable_all, perf NMI and throttling

amd_pmu_enable_all() does:

      if (!test_bit(idx, cpuc->active_mask))
              continue;

      amd_pmu_enable_event(cpuc->events[idx]);

A perf NMI of another event can come between these two steps. Perf NMI
handler internally disables and enables _all_ events, including the one
which nmi-intercepted amd_pmu_enable_all() was in process of enabling.
If that unintentionally enabled event has very low sampling period and
causes immediate successive NMI, causing the event to be throttled,
cpuc->events[idx] and cpuc->active_mask gets cleared by x86_pmu_stop().
This will result in amd_pmu_enable_event() getting called with event=NULL
when amd_pmu_enable_all() resumes after handling the NMIs. This causes a
kernel crash:

  BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  [...]
  Call Trace:
   <TASK>
   amd_pmu_enable_all+0x68/0xb0
   ctx_resched+0xd9/0x150
   event_function+0xb8/0x130
   ? hrtimer_start_range_ns+0x141/0x4a0
   ? perf_duration_warn+0x30/0x30
   remote_function+0x4d/0x60
   __flush_smp_call_function_queue+0xc4/0x500
   flush_smp_call_function_queue+0x11d/0x1b0
   do_idle+0x18f/0x2d0
   cpu_startup_entry+0x19/0x20
   start_secondary+0x121/0x160
   secondary_startup_64_no_verify+0xe5/0xeb
   </TASK>

amd_pmu_disable_all()/amd_pmu_enable_all() calls inside perf NMI handler
were recently added as part of BRS enablement but I'm not sure whether
we really need them. We can just disable BRS in the beginning and enable
it back while returning from NMI. This will solve the issue by not
enabling those events whose active_masks are set but are not yet enabled
in hw pmu.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/baa014b9543c8e5e94f5d15b66abfe60750b8284; https://git.kernel.org/stable/c/fd5e454b856ed86b090336e269695d9908609b71
CVE: CVE-2022-49782
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

perf: Improve missing SIGTRAP checking

To catch missing SIGTRAP we employ a WARN in __perf_event_overflow(),
which fires if pending_sigtrap was already set: returning to user space
without consuming pending_sigtrap, and then having the event fire again
would re-enter the kernel and trigger the WARN.

This, however, seemed to miss the case where some events not associated
with progress in the user space task can fire and the interrupt handler
runs before the IRQ work meant to consume pending_sigtrap (and generate
the SIGTRAP).

syzbot gifted us this stack trace:

 | WARNING: CPU: 0 PID: 3607 at kernel/events/core.c:9313 __perf_event_overflow
 | Modules linked in:
 | CPU: 0 PID: 3607 Comm: syz-executor100 Not tainted 6.1.0-rc2-syzkaller-00073-g88619e77b33d #0
 | Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022
 | RIP: 0010:__perf_event_overflow+0x498/0x540 kernel/events/core.c:9313
 | <...>
 | Call Trace:
 |  <TASK>
 |  perf_swevent_hrtimer+0x34f/0x3c0 kernel/events/core.c:10729
 |  __run_hrtimer kernel/time/hrtimer.c:1685 [inline]
 |  __hrtimer_run_queues+0x1c6/0xfb0 kernel/time/hrtimer.c:1749
 |  hrtimer_interrupt+0x31c/0x790 kernel/time/hrtimer.c:1811
 |  local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1096 [inline]
 |  __sysvec_apic_timer_interrupt+0x17c/0x640 arch/x86/kernel/apic/apic.c:1113
 |  sysvec_apic_timer_interrupt+0x40/0xc0 arch/x86/kernel/apic/apic.c:1107
 |  asm_sysvec_apic_timer_interrupt+0x16/0x20 arch/x86/include/asm/idtentry.h:649
 | <...>
 |  </TASK>

In this case, syzbot produced a program with event type
PERF_TYPE_SOFTWARE and config PERF_COUNT_SW_CPU_CLOCK. The hrtimer
manages to fire again before the IRQ work got a chance to run, all while
never having returned to user space.

Improve the WARN to check for real progress in user space: approximate
this by storing a 32-bit hash of the current IP into pending_sigtrap,
and if an event fires while pending_sigtrap still matches the previous
IP, we assume no progress (false negatives are possible given we could
return to user space and trigger again on the same IP).
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-674
References: https://git.kernel.org/stable/c/35c60b4e8ca76712dd03bafe2598e[PII_REDACTED]6; https://git.kernel.org/stable/c/b09221f1b4944d2866d06ac35e59d7a6f8916c9f; https://git.kernel.org/stable/c/bb88f9695460bec25aa30ba[PII_REDACTED]cf6c8af
CVE: CVE-2022-49783
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/fpu: Drop fpregs lock before inheriting FPU permissions

Mike Galbraith reported the following against an old fork of preempt-rt
but the same issue also applies to the current preempt-rt tree.

   BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46
   in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: systemd
   preempt_count: 1, expected: 0
   RCU nest depth: 0, expected: 0
   Preemption disabled at:
   fpu_clone
   CPU: 6 PID: 1 Comm: systemd Tainted: G            E       (unreleased)
   Call Trace:
    <TASK>
    dump_stack_lvl
    ? fpu_clone
    __might_resched
    rt_spin_lock
    fpu_clone
    ? copy_thread
    ? copy_process
    ? shmem_alloc_inode
    ? kmem_cache_alloc
    ? kernel_clone
    ? __do_sys_clone
    ? do_syscall_64
    ? __x64_sys_rt_sigprocmask
    ? syscall_exit_to_user_mode
    ? do_syscall_64
    ? syscall_exit_to_user_mode
    ? do_syscall_64
    ? syscall_exit_to_user_mode
    ? do_syscall_64
    ? exc_page_fault
    ? entry_SYSCALL_64_after_hwframe
    </TASK>

Mike says:

  The splat comes from fpu_inherit_perms() being called under fpregs_lock(),
  and us reaching the spin_lock_irq() therein due to fpu_state_size_dynamic()
  returning true despite static key __fpu_state_size_dynamic having never
  been enabled.

Mike's assessment looks correct. fpregs_lock on a PREEMPT_RT kernel disables
preemption so calling spin_lock_irq() in fpu_inherit_perms() is unsafe. This
problem exists since commit

  9e798e9aa14c ("x86/fpu: Prepare fpu_clone() for dynamically enabled features").

Even though the original bug report should not have enabled the paths at
all, the bug still exists.

fpregs_lock is necessary when editing the FPU registers or a task's FP
state but it is not necessary for fpu_inherit_perms(). The only write
of any FP state in fpu_inherit_perms() is for the new child which is
not running yet and cannot context switch or be borrowed by a kernel
thread yet. Hence, fpregs_lock is not protecting anything in the new
child until clone() completes and can be dropped earlier. The siglock
still needs to be acquired by fpu_inherit_perms() as the read of the
parent's permissions has to be serialised.

  [ bp: Cleanup splat. ]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/36b038791e1e2baea892e[PII_REDACTED]fd14894b4; https://git.kernel.org/stable/c/c6e8a7a1780af3da65e78a615f7d0874da6aabb0
CVE: CVE-2022-49784
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

perf/x86/amd/uncore: Fix memory leak for events array

When a CPU comes online, the per-CPU NB and LLC uncore contexts are
freed but not the events array within the context structure. This
causes a memory leak as identified by the kmemleak detector.

  [...]
  unreferenced object 0xffff8c5944b8e320 (size 32):
    comm "swapper/0", pid 1, jiffies[PII_REDACTED] (age 151.072s)
    hex dump (first 32 bytes):
      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    backtrace:
      [<[PII_REDACTED]59fb79>] amd_uncore_cpu_up_prepare+0xaf/0x230
      [<00000000ddc9e126>] cpuhp_invoke_callback+0x2cf/0x470
      [<[PII_REDACTED]e727d4>] cpuhp_issue_call+0x14d/0x170
      [<[PII_REDACTED]464d54>] __cpuhp_setup_state_cpuslocked+0x11e/0x330
      [<[PII_REDACTED]f67cbd>] __cpuhp_setup_state+0x6b/0x110
      [<[PII_REDACTED]365e0f>] amd_uncore_init+0x260/0x321
      [<[PII_REDACTED]9152d2>] do_one_initcall+0x3f/0x1f0
      [<000000002d0bd18d>] kernel_init_freeable+0x1ca/0x212
      [<[PII_REDACTED]be8dde>] kernel_init+0x11/0x120
      [<[PII_REDACTED]709e59>] ret_from_fork+0x22/0x30
  unreferenced object 0xffff8c5944b8dd40 (size 64):
    comm "swapper/0", pid 1, jiffies[PII_REDACTED] (age 151.072s)
    hex dump (first 32 bytes):
      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    backtrace:
      [<[PII_REDACTED]6efe8b>] amd_uncore_cpu_up_prepare+0x183/0x230
      [<00000000ddc9e126>] cpuhp_invoke_callback+0x2cf/0x470
      [<[PII_REDACTED]e727d4>] cpuhp_issue_call+0x14d/0x170
      [<[PII_REDACTED]464d54>] __cpuhp_setup_state_cpuslocked+0x11e/0x330
      [<[PII_REDACTED]f67cbd>] __cpuhp_setup_state+0x6b/0x110
      [<[PII_REDACTED]365e0f>] amd_uncore_init+0x260/0x321
      [<[PII_REDACTED]9152d2>] do_one_initcall+0x3f/0x1f0
      [<000000002d0bd18d>] kernel_init_freeable+0x1ca/0x212
      [<[PII_REDACTED]be8dde>] kernel_init+0x11/0x120
      [<[PII_REDACTED]709e59>] ret_from_fork+0x22/0x30
  [...]

Fix the problem by freeing the events array before freeing the uncore
context.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/bdfe34597139cfcecd47a2eb97fea44d77157491; https://git.kernel.org/stable/c/f75be9885d49e3717de962345c4572ddab52b178
CVE: CVE-2022-49785
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/sgx: Add overflow check in sgx_validate_offset_length()

sgx_validate_offset_length() function verifies "offset" and "length"
arguments provided by userspace, but was missing an overflow check on
their addition. Add it.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3b1c10fb754b0b67165e3f055a4208e5ba26dc89; https://git.kernel.org/stable/c/5277e3d633a5d4157987f4aff068caa55e36db19; https://git.kernel.org/stable/c/f0861f49bd946ff94fce4f82509c45e167f63690
CVE: CVE-2022-49786
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

blk-cgroup: properly pin the parent in blkcg_css_online

blkcg_css_online is supposed to pin the blkcg of the parent, but
397c9f46ee4d refactored things and along the way, changed it to pin the
css instead.  This results in extra pins, and we end up leaking blkcgs
and cgroups.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/d118247e404d6338f7b90636a3c6b95a387ed163; https://git.kernel.org/stable/c/d7dbd43f4a828fa1d9a8614d5b0ac40aee6375fe
CVE: CVE-2022-49787
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

mmc: sdhci-pci: Fix possible memory leak caused by missing pci_dev_put()

pci_get_device() will increase the reference count for the returned
pci_dev. We need to use pci_dev_put() to decrease the reference count
before amd_probe() returns. There is no problem for the 'smbus_dev ==
NULL' branch because pci_dev_put() can also handle the NULL input
parameter case.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/222cfa0118aa68687ace74aab8fdf77ce8fbd7e6; https://git.kernel.org/stable/c/27f712cd47d65e14cd52cc32a23d42aeef583d5d; https://git.kernel.org/stable/c/35bca18092685b488003509fef7055aa2d4f2ebc
CVE: CVE-2022-49788
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

misc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram()

`struct vmci_event_qp` allocated by qp_notify_peer() contains padding,
which may carry uninitialized data to the userspace, as observed by
KMSAN:

  BUG: KMSAN: kernel-infoleak in instrument_copy_to_user ./include/linux/instrumented.h:121
   instrument_copy_to_user ./include/linux/instrumented.h:121
   _copy_to_user+0x5f/0xb0 lib/usercopy.c:33
   copy_to_user ./include/linux/uaccess.h:169
   vmci_host_do_receive_datagram drivers/misc/vmw_vmci/vmci_host.c:431
   vmci_host_unlocked_ioctl+0x33d/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:925
   vfs_ioctl fs/ioctl.c:51
  ...

  Uninit was stored to memory at:
   kmemdup+0x74/0xb0 mm/util.c:131
   dg_dispatch_as_host drivers/misc/vmw_vmci/vmci_datagram.c:271
   vmci_datagram_dispatch+0x4f8/0xfc0 drivers/misc/vmw_vmci/vmci_datagram.c:339
   qp_notify_peer+0x19a/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1479
   qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662
   qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750
   vmci_qp_broker_alloc+0x96/0xd0 drivers/misc/vmw_vmci/vmci_queue_pair.c:1940
   vmci_host_do_alloc_queuepair drivers/misc/vmw_vmci/vmci_host.c:488
   vmci_host_unlocked_ioctl+0x24fd/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:927
  ...

  Local variable ev created at:
   qp_notify_peer+0x54/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1456
   qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662
   qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750

  Bytes 28-31 of 48 are uninitialized
  Memory access of size 48 starts at ffff888035155e00
  Data copied to user address [PII_REDACTED]

Use memset() to prevent the infoleaks.

Also speculatively fix qp_notify_peer_local(), which may suffer from the
same problem.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/5a275528025ae4bc7e[PII_REDACTED]dfebf84b2fad; https://git.kernel.org/stable/c/62634b43d3c4e1bf62fd540196f7081bf0885c0a; https://git.kernel.org/stable/c/76c50d77b928a33e5290aaa9fdc10e88254ff8c7
CVE: CVE-2022-49790
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

Input: iforce - invert valid length check when fetching device IDs

syzbot is reporting uninitialized value at iforce_init_device() [1], for
commit 6ac0aec6b0a6 ("Input: iforce - allow callers supply data buffer
when fetching device IDs") is checking that valid length is shorter than
bytes to read. Since iforce_get_id_packet() stores valid length when
returning 0, the caller needs to check that valid length is longer than or
equals to bytes to read.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/24cc679abbf31477d0cc6106ec83c2fbae6b3cdf; https://git.kernel.org/stable/c/5d53797ce7ce8fb1d95a5bebc5efa9418c4217a3; https://git.kernel.org/stable/c/6365569d62a75ddf53fb0c2936c16587a365984c
CVE: CVE-2022-49791
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

io_uring: fix multishot accept request leaks

Having REQ_F_POLLED set doesn't guarantee that the request is
executed as a multishot from the polling path. Fortunately for us, if
the code thinks it's multishot issue when it's not, it can only ask to
skip completion so leaking the request. Use issue_flags to mark
multipoll issues.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/0e4626de856ef8f25ecd9c716e76d4f95ce95639; https://git.kernel.org/stable/c/[PII_REDACTED]8a874c4290ef93b84a78f4f1dac51b
CVE: CVE-2022-49792
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: adc: mp2629: fix potential array out of bound access

Add sentinel at end of maps to avoid potential array out of
bound access in iio core.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/1678d4abb2dc2ca3b05b998a9d88616976e4f947; https://git.kernel.org/stable/c/399b2105a2240e730b9f3880bd8f154247539aa7; https://git.kernel.org/stable/c/ca1547ab15f48dc81624183ae17a2fd1bad06dfc
CVE: CVE-2022-49793
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: trigger: sysfs: fix possible memory leak in iio_sysfs_trig_init()

dev_set_name() allocates memory for name, it need be freed
when device_add() fails, call put_device() to give up the
reference that hold in device_initialize(), so that it can
be freed in kobject_cleanup() when the refcount hit to 0.

Fault injection test can trigger this:

unreferenced object 0xffff8e8340a7b4c0 (size 32):
  comm "modprobe", pid 243, jiffies[PII_REDACTED] (age 48.845s)
  hex dump (first 32 bytes):
    69 69 6f 5f 73 79 73 66 73 5f 74 72 69 67 67 65  iio_sysfs_trigge
    72 00 a7 40 83 8e ff ff 00 86 13 c4 f6 ee ff ff  r..@............
  backtrace:
    [<[PII_REDACTED]999de8>] __kmem_cache_alloc_node+0x1e9/0x360
    [<[PII_REDACTED]7fd30b>] __kmalloc_node_track_caller+0x44/0x1a0
    [<[PII_REDACTED]36c520>] kstrdup+0x2d/0x60
    [<[PII_REDACTED]f84da2>] kobject_set_name_vargs+0x1e/0x90
    [<[PII_REDACTED]efe493>] dev_set_name+0x4e/0x70
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/0dd52e141afde089304de470148d311b05c14564; https://git.kernel.org/stable/c/2c4e65285bdea23fd36d2ff376006ac64db6f42e; https://git.kernel.org/stable/c/5a39382aa5411d64b25a71516c2c7480aab13bb7
CVE: CVE-2022-49794
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: adc: at91_adc: fix possible memory leak in at91_adc_allocate_trigger()

If iio_trigger_register() returns error, it should call iio_trigger_free()
to give up the reference that hold in iio_trigger_alloc(), so that it can
call iio_trig_release() to free memory when the refcount hit to 0.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/1bf8c0aff8fb5c4edf3ba6728e6bedbd610d7f4b; https://git.kernel.org/stable/c/2b29a7f2d52fb5281b30cf61c947d88bab18a29b; https://git.kernel.org/stable/c/65f20301607d07ee279b0804d11a05a62a6c1a1c
CVE: CVE-2022-49795
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

rethook: fix a potential memleak in rethook_alloc()

In rethook_alloc(), the variable rh is not freed or passed out
if handler is NULL, which could lead to a memleak, fix it.

[Masami: Add "rethook:" tag to the title.]

Acke-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/0a1ebe35cb3b7aa1f4b26b37e2a0b9ae68dc4ffb; https://git.kernel.org/stable/c/cbc5d1f9a8cc40ba2bc6779b36d2ea1f65bc027c