deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-50562
Published: 2025-10-22
Description: In the Linux kernel, the following vulnerability has been resolved:

tpm: acpi: Call acpi_put_table() to fix memory leak

The start and length of the event log area are obtained from
TPM2 or TCPA table, so we call acpi_get_table() to get the
ACPI information, but the acpi_get_table() should be coupled with
acpi_put_table() to release the ACPI memory, add the acpi_put_table()
properly to fix the memory leak.

While we are at it, remove the redundant empty line at the
end of the tpm_read_log_acpi().
References: https://git.kernel.org/stable/c/638cd298dfebce46919cbd6cf[PII_REDACTED]f506d; https://git.kernel.org/stable/c/694a3d66f493afd77c704c6de91d9be4d6e004e4; https://git.kernel.org/stable/c/8740a12ca2e2959531ad253bac99ada338b33d80
CVE: CVE-2022-50563
Published: 2025-10-22
Description: In the Linux kernel, the following vulnerability has been resolved:

dm thin: Fix UAF in run_timer_softirq()

When dm_resume() and dm_destroy() are concurrent, it will
lead to UAF, as follows:

 BUG: KASAN: use-after-free in __run_timers+0x173/0x710
 Write of size 8 at addr ffff88816d9490f0 by task swapper/0/0
<snip>
 Call Trace:
  <IRQ>
  dump_stack_lvl+0x73/0x9f
  print_report.cold+0x132/0xaa2
  _raw_spin_lock_irqsave+0xcd/0x160
  __run_timers+0x173/0x710
  kasan_report+0xad/0x110
  __run_timers+0x173/0x710
  __asan_store8+0x9c/0x140
  __run_timers+0x173/0x710
  call_timer_fn+0x310/0x310
  pvclock_clocksource_read+0xfa/0x250
  kvm_clock_read+0x2c/0x70
  kvm_clock_get_cycles+0xd/0x20
  ktime_get+0x5c/0x110
  lapic_next_event+0x38/0x50
  clockevents_program_event+0xf1/0x1e0
  run_timer_softirq+0x49/0x90
  __do_softirq+0x16e/0x62c
  __irq_exit_rcu+0x1fa/0x270
  irq_exit_rcu+0x12/0x20
  sysvec_apic_timer_interrupt+0x8e/0xc0

One of the concurrency UAF can be shown as below:

        use                                  free
do_resume                           |
  __find_device_hash_cell           |
    dm_get                          |
      atomic_inc(&md->holders)      |
                                    | dm_destroy
                                    |   __dm_destroy
                                    |     if (!dm_suspended_md(md))
                                    |     atomic_read(&md->holders)
                                    |     msleep(1)
  dm_resume                         |
    __dm_resume                     |
      dm_table_resume_targets       |
        pool_resume                 |
          do_waker  #add delay work |
  dm_put                            |
    atomic_dec(&md->holders)        |
                                    |     dm_table_destroy
                                    |       pool_dtr
                                    |         __pool_dec
                                    |           __pool_destroy
                                    |             destroy_workqueue
                                    |             kfree(pool) # free pool
        time out
__do_softirq
  run_timer_softirq # pool has already been freed

This can be easily reproduced using:
  1. create thin-pool
  2. dmsetup suspend pool
  3. dmsetup resume pool
  4. dmsetup remove_all # Concurrent with 3

The root cause of this UAF bug is that dm_resume() adds timer after
dm_destroy() skips cancelling the timer because of suspend status.
After timeout, it will call run_timer_softirq(), however pool has
already been freed. The concurrency UAF bug will happen.

Therefore, cancelling timer again in __pool_destroy().
References: https://git.kernel.org/stable/c/34cd15d83b7206188d440b29b68084fcafde9395; https://git.kernel.org/stable/c/34fe9c2251f19786a6689149a6212c6c0de1d63b; https://git.kernel.org/stable/c/550a4fac7ecfee5bac6a0dd772456ca62fb72f46
CVE: CVE-2022-50564
Published: 2025-10-22
Description: In the Linux kernel, the following vulnerability has been resolved:

s390/netiucv: Fix return type of netiucv_tx()

With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:

  drivers/s390/net/netiucv.c:1854:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict]
          .ndo_start_xmit         = netiucv_tx,
                                    ^~~~~~~~~~

->ndo_start_xmit() in 'struct net_device_ops' expects a return type of
'netdev_tx_t', not 'int'. Adjust the return type of netiucv_tx() to
match the prototype's to resolve the warning and potential CFI failure,
should s390 select ARCH_SUPPORTS_CFI_CLANG in the future.

Additionally, while in the area, remove a comment block that is no
longer relevant.
References: https://git.kernel.org/stable/c/3ac0217ca9186c2f9af9a0113a331a42aa847894; https://git.kernel.org/stable/c/4bee3c75d5bf7c2b5dc0b520410eb40449e5da31; https://git.kernel.org/stable/c/85d[PII_REDACTED]55425df8618ccbebbc336f5acc5
CVE: CVE-2022-50565
Published: 2025-10-22
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: plfxlc: fix potential memory leak in __lf_x_usb_enable_rx()

urbs does not be freed in exception paths in __lf_x_usb_enable_rx().
That will trigger memory leak. To fix it, add kfree() for urbs within
"error" label. Compile tested only.
References: https://git.kernel.org/stable/c/286464463a05cb4bad80b134e24f8ffaab20bee4; https://git.kernel.org/stable/c/895b3b06efc285c1245242e9638b9ae251dc13ec; https://git.kernel.org/stable/c/fce7e46273649d9cdcd98d89551975a65f206a14
CVE: CVE-2022-50566
Published: 2025-10-22
Description: In the Linux kernel, the following vulnerability has been resolved:

mtd: Fix device name leak when register device failed in add_mtd_device()

There is a kmemleak when register device failed:
  unreferenced object 0xffff888101aab550 (size 8):
    comm "insmod", pid 3922, jiffies[PII_REDACTED] (age 925.408s)
    hex dump (first 8 bytes):
      6d 74 64 30 00 88 ff ff                          mtd0....
    backtrace:
      [<00000000bde26724>] __kmalloc_node_track_caller+0x4e/0x150
      [<000000003c32b416>] kvasprintf+0xb0/0x130
      [<000000001f7a8f15>] kobject_set_name_vargs+0x2f/0xb0
      [<000000006e781163>] dev_set_name+0xab/0xe0
      [<00000000e30d0c78>] add_mtd_device+0x4bb/0x700
      [<00000000f3d34de7>] mtd_device_parse_register+0x2ac/0x3f0
      [<00000000c0d88488>] 0xffffffffa0238457
      [<00000000b40d0922>] 0xffffffffa02a008f
      [<[PII_REDACTED]d17b9d>] do_one_initcall+0x87/0x2a0
      [<[PII_REDACTED]0f6ca6>] do_init_module+0xdf/0x320
      [<000000007b6768fe>] load_module+0x2f98/0x3330
      [<[PII_REDACTED]6bed5a>] __do_sys_finit_module+0x113/0x1b0
      [<[PII_REDACTED]4c2290>] do_syscall_64+0x35/0x80
      [<000000004c6a8d97>] entry_SYSCALL_64_after_hwframe+0x46/0xb0

If register device failed, should call put_device() to give up the
reference.
References: https://git.kernel.org/stable/c/1b172fb05d6315ecec082fd7544a3390e96f0d7e; https://git.kernel.org/stable/c/2302e2dc42b1f84f951c725ce742fc21c5a1e151; https://git.kernel.org/stable/c/330bc5533e8a8ed69cb951d5a8edce9bddb9db21
CVE: CVE-2022-50567
Published: 2025-10-22
Description: In the Linux kernel, the following vulnerability has been resolved:

fs: jfs: fix shift-out-of-bounds in dbAllocAG

Syzbot found a crash : UBSAN: shift-out-of-bounds in dbAllocAG. The
underlying bug is the missing check of bmp->db_agl2size. The field can
be greater than 64 and trigger the shift-out-of-bounds.

Fix this bug by adding a check of bmp->db_agl2size in dbMount since this
field is used in many following functions. The upper bound for this
field is L2MAXL2SIZE - L2MAXAG, thanks for the help of Dave Kleikamp.
Note that, for maintenance, I reorganized error handling code of dbMount.
References: https://git.kernel.org/stable/c/0536f76a2bca83d1a3740517ba22cc93a44b3099; https://git.kernel.org/stable/c/2c575c8905f7a8b32d5611b91856b69bac2a5bf1; https://git.kernel.org/stable/c/3115313cf03113e87c87adee18ee49a20bbdb9ba
CVE: CVE-2022-50568
Published: 2025-10-22
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: f_hid: fix f_hidg lifetime vs cdev

The embedded struct cdev does not have its lifetime correctly tied to
the enclosing struct f_hidg, so there is a use-after-free if /dev/hidgN
is held open while the gadget is deleted.

This can readily be replicated with libusbgx's example programs (for
conciseness - operating directly via configfs is equivalent):

	gadget-hid
	exec 3<> /dev/hidg0
	gadget-vid-pid-remove
	exec 3<&-

Pull the existing device up in to struct f_hidg and make use of the
cdev_device_{add,del}() helpers.  This changes the lifetime of the
device object to match struct f_hidg, but note that it is still added
and deleted at the same time.
References: https://git.kernel.org/stable/c/1b6a53e447ec3d81623610c8c7ec5082b47dfdce; https://git.kernel.org/stable/c/1cd7f156f6389918f760687fbbf133c86da93162; https://git.kernel.org/stable/c/89ff3dfac604614287ad5aad9370c3f984ea3f4b
CVE: CVE-2022-50569
Published: 2025-10-22
Description: In the Linux kernel, the following vulnerability has been resolved:

xfrm: Update ipcomp_scratches with NULL when freed

Currently if ipcomp_alloc_scratches() fails to allocate memory
ipcomp_scratches holds obsolete address. So when we try to free the
percpu scratches using ipcomp_free_scratches() it tries to vfree non
existent vm area. Described below:

static void * __percpu *ipcomp_alloc_scratches(void)
{
        ...
        scratches = alloc_percpu(void *);
        if (!scratches)
                return NULL;
ipcomp_scratches does not know about this allocation failure.
Therefore holding the old obsolete address.
        ...
}

So when we free,

static void ipcomp_free_scratches(void)
{
        ...
        scratches = ipcomp_scratches;
Assigning obsolete address from ipcomp_scratches

        if (!scratches)
                return;

        for_each_possible_cpu(i)
               vfree(*per_cpu_ptr(scratches, i));
Trying to free non existent page, causing warning: trying to vfree
existent vm area.
        ...
}

Fix this breakage by updating ipcomp_scrtches with NULL when scratches
is freed
References: https://git.kernel.org/stable/c/[PII_REDACTED]1ef0f004b1d6a5714c5b8cd271ab61; https://git.kernel.org/stable/c/18373ed500f7cd53e24d9b0bd0f1c09d78dba87e; https://git.kernel.org/stable/c/1e8abde895b3ac6a368cbdb372e8800c49e73a28
CVE: CVE-2022-50570
Published: 2025-10-22
Description: In the Linux kernel, the following vulnerability has been resolved:

platform/chrome: fix memory corruption in ioctl

If "s_mem.bytes" is larger than the buffer size it leads to memory
corruption.
References: https://git.kernel.org/stable/c/0c2e[PII_REDACTED]644d[PII_REDACTED]a4ac54cf2a; https://git.kernel.org/stable/c/868fc93b615b9f6c2b0b[PII_REDACTED]fa6cd66acc; https://git.kernel.org/stable/c/8a07b45fd3c2dda24fad43639be5335a4595196a
CVE: CVE-2022-50571
Published: 2025-10-22
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: call __btrfs_remove_free_space_cache_locked on cache load failure

Now that lockdep is staying enabled through our entire CI runs I started
seeing the following stack in generic/475

------------[ cut here ]------------
WARNING: CPU: 1 PID: 2171864 at fs/btrfs/discard.c:604 btrfs_discard_update_discardable+0x98/0xb0
CPU: 1 PID: 2171864 Comm: kworker/u4:0 Not tainted 5.19.0-rc8+ #789
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
Workqueue: btrfs-cache btrfs_work_helper
RIP: 0010:btrfs_discard_update_discardable+0x98/0xb0
RSP: 0018:ffffb857c2f7bad0 EFLAGS: 00010246
RAX: [PII_REDACTED] RBX: ffff8c85c605c200 RCX: [PII_REDACTED]
RDX: [PII_REDACTED] RSI: ffffffff86807c5b RDI: ffffffff868a831e
RBP: ffff8c85c4c54000 R08: [PII_REDACTED] R09: [PII_REDACTED]
R10: ffff8c85c66932f0 R11: [PII_REDACTED] R12: ffff8c85c3899010
R13: ffff8c85d5be4f40 R14: ffff8c85c4c54000 R15: ffff8c86114bfa80
FS:  [PII_REDACTED](0000) GS:ffff8c863bd00000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 00007f2e7f168160 CR3:[PII_REDACTED]89a004 CR4:[PII_REDACTED]370ee0
Call Trace:

 __btrfs_remove_free_space_cache+0x27/0x30
 load_free_space_cache+0xad2/0xaf0
 caching_thread+0x40b/0x650
 ? lock_release+0x137/0x2d0
 btrfs_work_helper+0xf2/0x3e0
 ? lock_is_held_type+0xe2/0x140
 process_one_work+0x271/0x590
 ? process_one_work+0x590/0x590
 worker_thread+0x52/0x3b0
 ? process_one_work+0x590/0x590
 kthread+0xf0/0x120
 ? kthread_complete_and_exit+0x20/0x20
 ret_from_fork+0x1f/0x30

This is the code

        ctl = block_group->free_space_ctl;
        discard_ctl = &block_group->fs_info->discard_ctl;

        lockdep_assert_held(&ctl->tree_lock);

We have a temporary free space ctl for loading the free space cache in
order to avoid having allocations happening while we're loading the
cache.  When we hit an error we free it all up, however this also calls
btrfs_discard_update_discardable, which requires
block_group->free_space_ctl->tree_lock to be held.  However this is our
temporary ctl so this lock isn't held.  Fix this by calling
__btrfs_remove_free_space_cache_locked instead so that we only clean up
the entries and do not mess with the discardable stats.
References: https://git.kernel.org/stable/c/819a61301275dcc573e3f520be3dc2c8531bee2d; https://git.kernel.org/stable/c/8a1ae2781dee9fc21ca82db682d37bea4bd074ad
CVE: CVE-2022-50572
Published: 2025-10-22
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: audio-graph-card: fix refcount leak of cpu_ep in __graph_for_each_link()

The of_get_next_child() returns a node with refcount incremented, and
decrements the refcount of prev. So in the error path of the while loop,
of_node_put() needs be called for cpu_ep.
References: https://git.kernel.org/stable/c/06c9d468c06806dab752eb8e72addbf3792c1023; https://git.kernel.org/stable/c/49dad92af6892f46851af989ef3aa7cd7316c389; https://git.kernel.org/stable/c/4cc8431ec77a43ea106d8bde0860c61cfdda1cd0
CVE: CVE-2022-50573
Published: 2025-10-22
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7915: fix mt7915_rate_txpower_get() resource leaks

Coverity message: variable "buf" going out of scope leaks the storage.

Addresses-Coverity-ID: 1527799 ("Resource leaks")
References: https://git.kernel.org/stable/c/8b25301af01566f4b5a301fc1ad7c5d2b1788d7f; https://git.kernel.org/stable/c/ecff00802f60fa5d08c133d209ed984a455a41f8
CVE: CVE-2022-50574
Published: 2025-10-22
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/omap: dss: Fix refcount leak bugs

In dss_init_ports() and __dss_uninit_ports(), we should call
of_node_put() for the reference returned by of_graph_get_port_by_id()
in fail path or when it is not used anymore.
References: https://git.kernel.org/stable/c/1f340e1c1c74d11c45a6e32663829b26acd4f47b; https://git.kernel.org/stable/c/8b42057e62120813ebe9274f508fa785b7cab33a; https://git.kernel.org/stable/c/8f7c4114db841497e1148598e22548dd1f700b22
CVE: CVE-2022-50575
Published: 2025-10-22
Description: In the Linux kernel, the following vulnerability has been resolved:

xen/privcmd: Fix a possible warning in privcmd_ioctl_mmap_resource()

As 'kdata.num' is user-controlled data, if user tries to allocate
memory larger than(>=) MAX_ORDER, then kcalloc() will fail, it
creates a stack trace and messes up dmesg with a warning.

Call trace:
-> privcmd_ioctl
--> privcmd_ioctl_mmap_resource

Add __GFP_NOWARN in order to avoid too large allocation warning.
This is detected by static analysis using smatch.
References: https://git.kernel.org/stable/c/0bf874183b32eae2cc20e3c5be38ec3d33e7e564; https://git.kernel.org/stable/c/46026bb057c35f5bb111bf95e00cd8366d2e34d4; https://git.kernel.org/stable/c/4da411086f5ab32f811a89ef804980ec106ebb65
CVE: CVE-2022-50576
Published: 2025-10-22
Description: In the Linux kernel, the following vulnerability has been resolved:

serial: pch: Fix PCI device refcount leak in pch_request_dma()

As comment of pci_get_slot() says, it returns a pci_device with its
refcount increased. The caller must decrement the reference count by
calling pci_dev_put().

Since 'dma_dev' is only used to filter the channel in filter(), we can
call pci_dev_put() before exiting from pch_request_dma(). Add the
missing pci_dev_put() for the normal and error path.
References: https://git.kernel.org/stable/c/07f4ca68b0f6bf84b6b391c14b59fd179fcde9c5; https://git.kernel.org/stable/c/4f5d28865c665c9064de631a518f9bc8099d9ce4; https://git.kernel.org/stable/c/516614a371c26e3334625b4bca19a5362bf658d6
CVE: CVE-2022-50577
Published: 2025-10-22
Description: In the Linux kernel, the following vulnerability has been resolved:

ima: Fix memory leak in __ima_inode_hash()

Commit f3cc6b25dcc5 ("ima: always measure and audit files in policy") lets
measurement or audit happen even if the file digest cannot be calculated.

As a result, iint->ima_hash could have been allocated despite
ima_collect_measurement() returning an error.

Since ima_hash belongs to a temporary inode metadata structure, declared
at the beginning of __ima_inode_hash(), just add a kfree() call if
ima_collect_measurement() returns an error different from -ENOMEM (in that
case, ima_hash should not have been allocated).
References: https://git.kernel.org/stable/c/8c1d6a050a0f16e0a9d32eaf53b965c77279c6f8; https://git.kernel.org/stable/c/c4df8cb38f139ed9f4296868c0a6f15a26e8c491; https://git.kernel.org/stable/c/f375bcf69f58fd0744c9dfd1b6b891a27301d67b
CVE: CVE-2022-50578
Published: 2025-10-22
Description: In the Linux kernel, the following vulnerability has been resolved:

class: fix possible memory leak in __class_register()

If class_add_groups() returns error, the 'cp->subsys' need be
unregister, and the 'cp' need be freed.

We can not call kset_unregister() here, because the 'cls' will
be freed in callback function class_release() and it's also
freed in caller's error path, it will cause double free.

So fix this by calling kobject_del() and kfree_const(name) to
cleanup kobject. Besides, call kfree() to free the 'cp'.

Fault injection test can trigger this:

unreferenced object 0xffff888102fa8190 (size 8):
  comm "modprobe", pid 502, jiffies[PII_REDACTED] (age 49.296s)
  hex dump (first 8 bytes):
    70 6b 74 63 64 76 64 00                          pktcdvd.
  backtrace:
    [<00000000e7c7703d>] __kmalloc_track_caller+0x1ae/0x320
    [<000000005e4d70bc>] kstrdup+0x3a/0x70
    [<00000000c2e5e85a>] kstrdup_const+0x68/0x80
    [<[PII_REDACTED]49a8c7>] kvasprintf_const+0x10b/0x190
    [<[PII_REDACTED]>] kobject_set_name_vargs+0x56/0x150
    [<[PII_REDACTED]7219c9>] kobject_set_name+0xab/0xe0
    [<[PII_REDACTED]f1ea4e>] __class_register+0x15c/0x49a

unreferenced object 0xffff[PII_REDACTED]00 (size 1024):
  comm "modprobe", pid 502, jiffies[PII_REDACTED] (age 49.296s)
  hex dump (first 32 bytes):
    00 40 27 37 80 88 ff ff 00 40 27 37 80 88 ff ff  .@'7.....@'7....
    00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00  .....N..........
  backtrace:
    [<[PII_REDACTED]1f9600>] kmem_cache_alloc_trace+0x17c/0x2f0
    [<00000000ecf3dd95>] __class_register+0x86/0x49a
References: https://git.kernel.org/stable/c/18a[PII_REDACTED]cf8e1b8a933de08122fc50676cd; https://git.kernel.org/stable/c/3bb9c92c27624ad076419a70f2b1a30cd1f8bbbd; https://git.kernel.org/stable/c/3e0efc3f3f5e5c73996782f8db69963e501bb878
CVE: CVE-2022-50580
Published: 2025-10-22
Description: In the Linux kernel, the following vulnerability has been resolved:

blk-throttle: prevent overflow while calculating wait time

There is a problem found by code review in tg_with_in_bps_limit() that
'bps_limit * jiffy_elapsed_rnd' might overflow. Fix the problem by
calling mul_u64_u64_div_u64() instead.
References: https://git.kernel.org/stable/c/19c010ae44f0ce52b[PII_REDACTED]a61a092ee0cf4; https://git.kernel.org/stable/c/70b2adb1d698fbc63d3b3848c452524dc15872c5; https://git.kernel.org/stable/c/8d6bbaada2e0a65f9012ac4c[PII_REDACTED]e7237a
CVE: CVE-2022-50581
Published: 2025-10-22
Description: In the Linux kernel, the following vulnerability has been resolved:

hfs: fix OOB Read in __hfs_brec_find

Syzbot reported a OOB read bug:

==================================================================
BUG: KASAN: slab-out-of-bounds in hfs_strcmp+0x117/0x190
fs/hfs/string.c:84
Read of size 1 at addr ffff88807eb62c4e by task kworker/u4:1/11
CPU: 1 PID: 11 Comm: kworker/u4:1 Not tainted
6.1.0-rc6-syzkaller-00308-g644e9524388a #0
Workqueue: writeback wb_workfn (flush-7:0)
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106
 print_address_description+0x74/0x340 mm/kasan/report.c:284
 print_report+0x107/0x1f0 mm/kasan/report.c:395
 kasan_report+0xcd/0x100 mm/kasan/report.c:495
 hfs_strcmp+0x117/0x190 fs/hfs/string.c:84
 __hfs_brec_find+0x213/0x5c0 fs/hfs/bfind.c:75
 hfs_brec_find+0x276/0x520 fs/hfs/bfind.c:138
 hfs_write_inode+0x34c/0xb40 fs/hfs/inode.c:462
 write_inode fs/fs-writeback.c:1440 [inline]

If the input inode of hfs_write_inode() is incorrect:
struct inode
  struct hfs_inode_info
    struct hfs_cat_key
      struct hfs_name
        u8 len # len is greater than HFS_NAMELEN(31) which is the
maximum length of an HFS filename

OOB read occurred:
hfs_write_inode()
  hfs_brec_find()
    __hfs_brec_find()
      hfs_cat_keycmp()
        hfs_strcmp() # OOB read occurred due to len is too large

Fix this by adding a Check on len in hfs_write_inode() before calling
hfs_brec_find().
References: https://git.kernel.org/stable/c/2344f17c0a89c181ab1a9fef57fd8c3bddfd6e30; https://git.kernel.org/stable/c/367296925c7625c3969d2a78d7a3e1dee161beb5; https://git.kernel.org/stable/c/4fd3a11804c8877ff11fec59c5c53f1635331e3e
CVE: CVE-2022-50582
Published: 2025-10-22
Description: In the Linux kernel, the following vulnerability has been resolved:

regulator: core: Prevent integer underflow

By using a ratio of delay to poll_enabled_time that is not integer
time_remaining underflows and does not exit the loop as expected.
As delay could be derived from DT and poll_enabled_time is defined
in the driver this can easily happen.

Use a signed iterator to make sure that the loop exits once
the remaining time is negative.
References: https://git.kernel.org/stable/c/8d8e16592022c9650df8aedfe6552ed478d7135b; https://git.kernel.org/stable/c/9f2395316e4845466cb9b5b9b15a171a2c91913c; https://git.kernel.org/stable/c/b051d9bf98bd9cea312b228e264eb6542a9beb67