deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-50761
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/xen: Fix memory leak in xen_init_lock_cpu()

In xen_init_lock_cpu(), the @name has allocated new string by kasprintf(),
if bind_ipi_to_irqhandler() fails, it should be freed, otherwise may lead
to a memory leak issue, fix it.
References: https://git.kernel.org/stable/c/07764d00c869a3390bd4f80412cc8b0e669e6c58; https://git.kernel.org/stable/c/29198f667f4486f9e227e11faf1411fcf4c82a66; https://git.kernel.org/stable/c/53ff99c76be611acea37d33133c[PII_REDACTED]865
CVE: CVE-2022-50762
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Avoid UBSAN error on true_sectors_per_clst()

syzbot reported UBSAN error as below:

[   76.901829][ T6677] ================================================================================
[   76.903908][ T6677] UBSAN: shift-out-of-bounds in fs/ntfs3/super.c:675:13
[   76.905363][ T6677] shift exponent -247 is negative

This patch avoid this error.
References: https://git.kernel.org/stable/c/4b51f27d4448c84957bce190292f75d4896d56b3; https://git.kernel.org/stable/c/8fe280ae85177c2323ae8c9849ff27a3a6b69506; https://git.kernel.org/stable/c/95afb464c86c6e9e95ea9e595282fa6f693072e8
CVE: CVE-2022-50763
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: marvell/octeontx - prevent integer overflows

The "code_length" value comes from the firmware file.  If your firmware
is untrusted realistically there is probably very little you can do to
protect yourself.  Still we try to limit the damage as much as possible.
Also Smatch marks any data read from the filesystem as untrusted and
prints warnings if it not capped correctly.

The "code_length * 2" can overflow.  The round_up(ucode_size, 16) +
sizeof() expression can overflow too.  Prevent these overflows.
References: https://git.kernel.org/stable/c/12acfa1059ad69aa352ddb2bf23ba1b831aff15f; https://git.kernel.org/stable/c/7bfa7d[PII_REDACTED]5c98091194e81e7685f9b7db; https://git.kernel.org/stable/c/8f5eee162e55175d9dac98b5e9b8da76449d2257
CVE: CVE-2022-50764
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ipv6/sit: use DEV_STATS_INC() to avoid data-races

syzbot/KCSAN reported that multiple cpus are updating dev->stats.tx_error
concurrently.

This is because sit tunnels are NETIF_F_LLTX, meaning their ndo_start_xmit()
is not protected by a spinlock.

While original KCSAN report was about tx path, rx path has the same issue.
References: https://git.kernel.org/stable/c/207501a986831174df09a36a8cb62a28f92f0dc8; https://git.kernel.org/stable/c/222cc04356984f3f98acfa756a69d4bed7c501ac; https://git.kernel.org/stable/c/4eed93bb3e57b8cc78d17166a14e40a73276015a
CVE: CVE-2022-50765
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

RISC-V: kexec: Fix memory leak of elf header buffer

This is reported by kmemleak detector:

unreferenced object 0xff[PII_REDACTED]d000 (size 4096):
  comm "kexec", pid 146, jiffies[PII_REDACTED] (age 64.792s)
  hex dump (first 32 bytes):
    7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00  .ELF............
    04 00 f3 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<[PII_REDACTED]6ca97c>] kmemleak_vmalloc+0x3c/0xbe
    [<[PII_REDACTED]9283d8>] __vmalloc_node_range+0x3ac/0x560
    [<00000000b4b3712a>] __vmalloc_node+0x56/0x62
    [<[PII_REDACTED]4f75e2>] vzalloc+0x2c/0x34
    [<00000000e9a00db9>] crash_prepare_elf64_headers+0x80/0x30c
    [<[PII_REDACTED]e8bf48>] elf_kexec_load+0x3e8/0x4ec
    [<[PII_REDACTED]548e09>] kexec_image_load_default+0x40/0x4c
    [<[PII_REDACTED]fbe1b4>] sys_kexec_file_load+0x1c4/0x322
    [<[PII_REDACTED]c62c03>] ret_from_syscall+0x0/0x2

In elf_kexec_load(), a buffer is allocated via vzalloc() to store elf
headers.  While it's not freed back to system when kdump kernel is
reloaded or unloaded, or when image->elf_header is successfully set and
then fails to load kdump kernel for some reason. Fix it by freeing the
buffer in arch_kimage_file_post_load_cleanup().
References: https://git.kernel.org/stable/c/090bfcfc9f14d05154893c67eeaecc56e894fbae; https://git.kernel.org/stable/c/cbc32023ddbdf4baa3d9dc513a2184a84080a5a2; https://git.kernel.org/stable/c/cdea2da6787583ecca[PII_REDACTED]3a2ac8d7cd21
CVE: CVE-2022-50766
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: set generation before calling btrfs_clean_tree_block in btrfs_init_new_buffer

syzbot is reporting uninit-value in btrfs_clean_tree_block() [1], for
commit bc877d285ca3dba2 ("btrfs: Deduplicate extent_buffer init code")
missed that btrfs_set_header_generation() in btrfs_init_new_buffer() must
not be moved to after clean_tree_block() because clean_tree_block() is
calling btrfs_header_generation() since commit 55c69072d6bd5be1 ("Btrfs:
Fix extent_buffer usage when nodesize != leafsize").

Since memzero_extent_buffer() will reset "struct btrfs_header" part, we
can't move btrfs_set_header_generation() to before memzero_extent_buffer().
Just re-add btrfs_set_header_generation() before btrfs_clean_tree_block().
References: https://git.kernel.org/stable/c/0a408c6212c16b9a2a1141d3c531247582ef8101; https://git.kernel.org/stable/c/89bc41c92d10b905c60f6ec13c9ef664a3555c54; https://git.kernel.org/stable/c/a687c2890fe4a2acaac6941fa4097a1264d8f3eb
CVE: CVE-2022-50767
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

fbdev: smscufx: Fix several use-after-free bugs

Several types of UAFs can occur when physically removing a USB device.

Adds ufx_ops_destroy() function to .fb_destroy of fb_ops, and
in this function, there is kref_put() that finally calls ufx_free().

This fix prevents multiple UAFs.
References: https://git.kernel.org/stable/c/3f40852d671072836fb7ae331a1f28a24223c4e8; https://git.kernel.org/stable/c/5385af2f89bc352fb70753ab41b2bb036190141f; https://git.kernel.org/stable/c/6f2075ea883e5d7730d0c9ebb1bb8e7a1a7e953f
CVE: CVE-2022-50768
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: smartpqi: Correct device removal for multi-actuator devices

Correct device count for multi-actuator drives which can cause kernel
panics.
References: https://git.kernel.org/stable/c/cc9befcbbb5ebce77726f938508700d913530035; https://git.kernel.org/stable/c/d1c8b86b4ab7e8588a8cfadbdd6f20adbb15c938; https://git.kernel.org/stable/c/e8e9e0c28901d34beb193b5ece52eb7c656f4042
CVE: CVE-2022-50769
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

mmc: mxcmmc: fix return value check of mmc_add_host()

mmc_add_host() may return error, if we ignore its return value, the memory
that allocated in mmc_alloc_host() will be leaked and it will lead a kernel
crash because of deleting not added device in the remove path.

So fix this by checking the return value and goto error path which will call
mmc_free_host().
References: https://git.kernel.org/stable/c/1cf0c1e58738b97e2de207846105b6a5d46622ee; https://git.kernel.org/stable/c/2d496050ded83b13b16f05e1fc0329b0210d2493; https://git.kernel.org/stable/c/32eb502c972dfc34413c9147418b3d94d870c2b8
CVE: CVE-2022-50770
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ocfs2: fix memory leak in ocfs2_mount_volume()

There is a memory leak reported by kmemleak:

  unreferenced object 0xffff88810cc65e60 (size 32):
    comm "mount.ocfs2", pid 23753, jiffies[PII_REDACTED] (age 34735.105s)
    hex dump (first 32 bytes):
      10 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01  ................
      01 01 01 01 01 01 01 01 00 00 00 00 00 00 00 00  ................
    backtrace:
      [<ffffffff8170f73d>] __kmalloc+0x4d/0x150
      [<ffffffffa0ac3f51>] ocfs2_compute_replay_slots+0x121/0x330 [ocfs2]
      [<ffffffffa0b65165>] ocfs2_check_volume+0x485/0x900 [ocfs2]
      [<ffffffffa0b68129>] ocfs2_mount_volume.isra.0+0x1e9/0x650 [ocfs2]
      [<ffffffffa0b7160b>] ocfs2_fill_super+0xe0b/0x1740 [ocfs2]
      [<ffffffff818e1fe2>] mount_bdev+0x312/0x400
      [<ffffffff819a086d>] legacy_get_tree+0xed/0x1d0
      [<ffffffff818de82d>] vfs_get_tree+0x7d/0x230
      [<ffffffff81957f92>] path_mount+0xd62/0x1760
      [<ffffffff81958a5a>] do_mount+0xca/0xe0
      [<ffffffff81958d3c>] __x64_sys_mount+0x12c/0x1a0
      [<ffffffff82f26f15>] do_syscall_64+0x35/0x80
      [<ffffffff8300006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0

This call stack is related to two problems.  Firstly, the ocfs2 super uses
"replay_map" to trace online/offline slots, in order to recover offline
slots during recovery and mount.  But when ocfs2_truncate_log_init()
returns an error in ocfs2_mount_volume(), the memory of "replay_map" will
not be freed in error handling path.  Secondly, the memory of "replay_map"
will not be freed if d_make_root() returns an error in ocfs2_fill_super().
But the memory of "replay_map" will be freed normally when completing
recovery and mount in ocfs2_complete_mount_recovery().

Fix the first problem by adding error handling path to free "replay_map"
when ocfs2_truncate_log_init() fails.  And fix the second problem by
calling ocfs2_free_replay_slots(osb) in the error handling path
"out_dismount".  In addition, since ocfs2_free_replay_slots() is static,
it is necessary to remove its static attribute and declare it in header
file.
References: https://git.kernel.org/stable/c/2b7e59ed2e77136e9360274f8f0fc208a003e95c; https://git.kernel.org/stable/c/4efe1d2db731bad19891e2fb9b338724b1f598cc; https://git.kernel.org/stable/c/50ab0ca3aff4da26037113d69f5a756d8c1a92cd
CVE: CVE-2022-50771
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

rcu: Fix __this_cpu_read() lockdep warning in rcu_force_quiescent_state()

Running rcutorture with non-zero fqs_duration module parameter in a
kernel built with CONFIG_PREEMPTION=y results in the following splat:

BUG: using __this_cpu_read() in preemptible [00000000]
code: rcu_torture_fqs/398
caller is __this_cpu_preempt_check+0x13/0x20
CPU: 3 PID: 398 Comm: rcu_torture_fqs Not tainted 6.0.0-rc1-yoctodev-standard+
Call Trace:
<TASK>
dump_stack_lvl+0x5b/0x86
dump_stack+0x10/0x16
check_preemption_disabled+0xe5/0xf0
__this_cpu_preempt_check+0x13/0x20
rcu_force_quiescent_state.part.0+0x1c/0x170
rcu_force_quiescent_state+0x1e/0x30
rcu_torture_fqs+0xca/0x160
? rcu_torture_boost+0x430/0x430
kthread+0x192/0x1d0
? kthread_complete_and_exit+0x30/0x30
ret_from_fork+0x22/0x30
</TASK>

The problem is that rcu_force_quiescent_state() uses __this_cpu_read()
in preemptible code instead of the proper raw_cpu_read().  This commit
therefore changes __this_cpu_read() to raw_cpu_read().
References: https://git.kernel.org/stable/c/3d92527a919edd1aa381bdd6c299dd75a8167396; https://git.kernel.org/stable/c/5a52380b8193cf8be6c4a6b94b86ef64ed80c0dc; https://git.kernel.org/stable/c/80a3e7ab477b3655615fc1627c88c248d4ad28d9
CVE: CVE-2022-50772
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

netdevsim: fix memory leak in nsim_bus_dev_new()

If device_register() failed in nsim_bus_dev_new(), the value of reference
in nsim_bus_dev->dev is 1. obj->name in nsim_bus_dev->dev will not be
released.

unreferenced object 0xffff88810352c480 (size 16):
  comm "echo", pid 5691, jiffies[PII_REDACTED] (age 133.270s)
  hex dump (first 16 bytes):
    6e 65 74 64 65 76 73 69 6d 31 00 00 00 00 00 00  netdevsim1......
  backtrace:
    [<000000005e2e5e26>] __kmalloc_node_track_caller+0x3a/0xb0
    [<[PII_REDACTED]ca4fc8>] kvasprintf+0xc3/0x160
    [<00000000aad09bcc>] kvasprintf_const+0x55/0x180
    [<000000009bac868d>] kobject_set_name_vargs+0x56/0x150
    [<000000007c1a5d70>] dev_set_name+0xbb/0xf0
    [<00000000ad0d126b>] device_add+0x1f8/0x1cb0
    [<00000000c222ae24>] new_device_store+0x3b6/0x5e0
    [<[PII_REDACTED]>] bus_attr_store+0x72/0xa0
    [<00000000cbb1833a>] sysfs_kf_write+0x106/0x160
    [<00000000d0dedb8a>] kernfs_fop_write_iter+0x3a8/0x5a0
    [<[PII_REDACTED]0b66e2>] vfs_write+0x8f0/0xc80
    [<[PII_REDACTED]bb39be>] ksys_write+0x106/0x210
    [<[PII_REDACTED]5e55a4>] do_syscall_64+0x35/0x80
    [<00000000eaa40bbc>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
References: https://git.kernel.org/stable/c/77579e[PII_REDACTED]fbd9662f03430dca5b50b086; https://git.kernel.org/stable/c/cf2010aa1c739bab067cbc90b690d28eaa0b47da
CVE: CVE-2022-50773
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: mts64: fix possible null-ptr-defer in snd_mts64_interrupt

I got a null-ptr-defer error report when I do the following tests
on the qemu platform:

make defconfig and CONFIG_PARPORT=m, CONFIG_PARPORT_PC=m,
CONFIG_SND_MTS64=m

Then making test scripts:
cat>test_mod1.sh<<EOF
modprobe snd-mts64
modprobe snd-mts64
EOF

Executing the script, perhaps several times, we will get a null-ptr-defer
report, as follow:

syzkaller:~# ./test_mod.sh
snd_mts64: probe of snd_mts64.0 failed with error -5
modprobe: ERROR: could not insert 'snd_mts64': No such device
 BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 0 P4D 0
 Oops: 0002 [#1] PREEMPT SMP PTI
 CPU: 0 PID: 205 Comm: modprobe Not tainted 6.1.0-rc8-00588-g76dcd734eca2 #6
 Call Trace:
  <IRQ>
  snd_mts64_interrupt+0x24/0xa0 [snd_mts64]
  parport_irq_handler+0x37/0x50 [parport]
  __handle_irq_event_percpu+0x39/0x190
  handle_irq_event_percpu+0xa/0x30
  handle_irq_event+0x2f/0x50
  handle_edge_irq+0x99/0x1b0
  __common_interrupt+0x5d/0x100
  common_interrupt+0xa0/0xc0
  </IRQ>
  <TASK>
  asm_common_interrupt+0x22/0x40
 RIP: 0010:_raw_write_unlock_irqrestore+0x11/0x30
  parport_claim+0xbd/0x230 [parport]
  snd_mts64_probe+0x14a/0x465 [snd_mts64]
  platform_probe+0x3f/0xa0
  really_probe+0x129/0x2c0
  __driver_probe_device+0x6d/0xc0
  driver_probe_device+0x1a/0xa0
  __device_attach_driver+0x7a/0xb0
  bus_for_each_drv+0x62/0xb0
  __device_attach+0xe4/0x180
  bus_probe_device+0x82/0xa0
  device_add+0x550/0x920
  platform_device_add+0x106/0x220
  snd_mts64_attach+0x2e/0x80 [snd_mts64]
  port_check+0x14/0x20 [parport]
  bus_for_each_dev+0x6e/0xc0
  __parport_register_driver+0x7c/0xb0 [parport]
  snd_mts64_module_init+0x31/0x1000 [snd_mts64]
  do_one_initcall+0x3c/0x1f0
  do_init_module+0x46/0x1c6
  load_module+0x1d8d/0x1e10
  __do_sys_finit_module+0xa2/0xf0
  do_syscall_64+0x37/0x90
  entry_SYSCALL_64_after_hwframe+0x63/0xcd
  </TASK>
 Kernel panic - not syncing: Fatal exception in interrupt
 Rebooting in 1 seconds..

The mts wa not initialized during interrupt,  we add check for
mts to fix this bug.
References: https://git.kernel.org/stable/c/[PII_REDACTED]219ce6ff380ec401f87308485c6ae3; https://git.kernel.org/stable/c/06ec592389f2be3199779ab823c4323dcfd2121f; https://git.kernel.org/stable/c/1a763c748acd5540ccc43306c57c9c6c5fb60884
CVE: CVE-2022-50774
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: qat - fix DMA transfer direction

When CONFIG_DMA_API_DEBUG is selected, while running the crypto self
test on the QAT crypto algorithms, the function add_dma_entry() reports
a warning similar to the one below, saying that overlapping mappings
are not supported. This occurs in tests where the input and the output
scatter list point to the same buffers (i.e. two different scatter lists
which point to the same chunks of memory).

The logic that implements the mapping uses the flag DMA_BIDIRECTIONAL
for both the input and the output scatter lists which leads to
overlapped write mappings. These are not supported by the DMA layer.

Fix by specifying the correct DMA transfer directions when mapping
buffers. For in-place operations where the input scatter list
matches the output scatter list, buffers are mapped once with
DMA_BIDIRECTIONAL, otherwise input buffers are mapped using the flag
DMA_TO_DEVICE and output buffers are mapped with DMA_FROM_DEVICE.
Overlapping a read mapping with a write mapping is a valid case in
dma-coherent devices like QAT.
The function that frees and unmaps the buffers, qat_alg_free_bufl()
has been changed accordingly to the changes to the mapping function.

   DMA-API: 4xxx 0000:06:00.0: cacheline tracking EEXIST, overlapping mappings aren't supported
   WARNING: CPU: 53 PID: 4362 at kernel/dma/debug.c:570 add_dma_entry+0x1e9/0x270
   ...
   Call Trace:
   dma_map_page_attrs+0x82/0x2d0
   ? preempt_count_add+0x6a/0xa0
   qat_alg_sgl_to_bufl+0x45b/0x990 [intel_qat]
   qat_alg_aead_dec+0x71/0x250 [intel_qat]
   crypto_aead_decrypt+0x3d/0x70
   test_aead_vec_cfg+0x649/0x810
   ? number+0x310/0x3a0
   ? vsnprintf+0x2a3/0x550
   ? scnprintf+0x42/0x70
   ? valid_sg_divisions.constprop.0+0x86/0xa0
   ? test_aead_vec+0xdf/0x120
   test_aead_vec+0xdf/0x120
   alg_test_aead+0x185/0x400
   alg_test+0x3d8/0x500
   ? crypto_acomp_scomp_free_ctx+0x30/0x30
   ? __schedule+0x32a/0x12a0
   ? ttwu_queue_wakelist+0xbf/0x110
   ? _raw_spin_unlock_irqrestore+0x23/0x40
   ? try_to_wake_up+0x83/0x570
   ? _raw_spin_unlock_irqrestore+0x23/0x40
   ? __set_cpus_allowed_ptr_locked+0xea/0x1b0
   ? crypto_acomp_scomp_free_ctx+0x30/0x30
   cryptomgr_test+0x27/0x50
   kthread+0xe6/0x110
   ? kthread_complete_and_exit+0x20/0x20
   ret_from_fork+0x1f/0x30
References: https://git.kernel.org/stable/c/1f1ab76e251521bd2fa5244473efcf663792745d; https://git.kernel.org/stable/c/426d5bc089e7731e36b514d1beca19e777a2d653; https://git.kernel.org/stable/c/429348d4f675e9eb418d0829064c4d7d06bd66a3
CVE: CVE-2022-50775
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/hns: Fix refcount leak in hns_roce_mmap

rdma_user_mmap_entry_get_pgoff() takes the reference.
Add missing rdma_user_mmap_entry_put() to release the reference.

Acked-by Haoyue Xu <xuhaoyue1@hisilicon.com>
References: https://git.kernel.org/stable/c/8abd2ff2256a2a99c11c7ecdcb[PII_REDACTED]620f; https://git.kernel.org/stable/c/cf6a05c8494a8ae7fec8e5f1229b45ca5b4bcd30; https://git.kernel.org/stable/c/fa87cf2e756efe809ee8683d4f282f4de962dab6
CVE: CVE-2022-50776
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: st: Fix memory leak in st_of_quadfs_setup()

If st_clk_register_quadfs_pll() fails, @lock should be freed before goto
@err_exit, otherwise will cause meory leak issue, fix it.
References: https://git.kernel.org/stable/c/081538ae5817631a2b99e8e75cce981060aab29f; https://git.kernel.org/stable/c/335ef7546c77e63154d6ea4d603b11274a85900e; https://git.kernel.org/stable/c/713ad301c2d49e88fe586b57ebac8f220a98e162
CVE: CVE-2022-50777
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

net: phy: xgmiitorgmii: Fix refcount leak in xgmiitorgmii_probe

of_phy_find_device() return device node with refcount incremented.
Call put_device() to relese it when not needed anymore.
References: https://git.kernel.org/stable/c/00616bd1913a4f879679e02dc08c2f501ca2bd4c; https://git.kernel.org/stable/c/106d0d33c9d1ec4ddeeffc1fdc717ff09953d4ed; https://git.kernel.org/stable/c/4d112f001612c79927c1ecf29522b34c4fa292e0
CVE: CVE-2022-50778
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

fortify: Fix __compiletime_strlen() under UBSAN_BOUNDS_LOCAL

With CONFIG_FORTIFY=y and CONFIG_UBSAN_LOCAL_BOUNDS=y enabled, we observe
a runtime panic while running Android's Compatibility Test Suite's (CTS)
android.hardware.input.cts.tests. This is stemming from a strlen()
call in hidinput_allocate().

__compiletime_strlen() is implemented in terms of __builtin_object_size(),
then does an array access to check for NUL-termination. A quirk of
__builtin_object_size() is that for strings whose values are runtime
dependent, __builtin_object_size(str, 1 or 0) returns the maximum size
of possible values when those sizes are determinable at compile time.
Example:

  static const char *v = "FOO BAR";
  static const char *y = "FOO BA";
  unsigned long x (int z) {
      // Returns 8, which is:
      // max(__builtin_object_size(v, 1), __builtin_object_size(y, 1))
      return __builtin_object_size(z ? v : y, 1);
  }

So when FORTIFY_SOURCE is enabled, the current implementation of
__compiletime_strlen() will try to access beyond the end of y at runtime
using the size of v. Mixed with UBSAN_LOCAL_BOUNDS we get a fault.

hidinput_allocate() has a local C string whose value is control flow
dependent on a switch statement, so __builtin_object_size(str, 1)
evaluates to the maximum string length, making all other cases fault on
the last character check. hidinput_allocate() could be cleaned up to
avoid runtime calls to strlen() since the local variable can only have
literal values, so there's no benefit to trying to fortify the strlen
call site there.

Perform a __builtin_constant_p() check against index 0 earlier in the
macro to filter out the control-flow-dependant case. Add a KUnit test
for checking the expected behavioral characteristics of FORTIFY_SOURCE
internals.
References: https://git.kernel.org/stable/c/5d59ad2bfb35fccfe2ad5e8bb8801f6224d3f7d4; https://git.kernel.org/stable/c/d07c0acb4f41cc42a0d[PII_REDACTED]5b3e4fa68c1; https://git.kernel.org/stable/c/ed42391164e6839a48aaf4c53eefda516835e799
CVE: CVE-2022-50779
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

orangefs: Fix kmemleak in orangefs_prepare_debugfs_help_string()

When insert and remove the orangefs module, then debug_help_string will
be leaked:

  unreferenced object 0xffff8881652ba000 (size 4096):
    comm "insmod", pid 1701, jiffies[PII_REDACTED] (age 13218.530s)
    hex dump (first 32 bytes):
      43 6c 69 65 6e 74 20 44 65 62 75 67 20 4b 65 79  Client Debug Key
      77 6f 72 64 73 20 61 72 65 20 75 6e 6b 6e 6f 77  words are unknow
    backtrace:
      [<[PII_REDACTED]e6f8e3>] kmalloc_trace+0x27/0xa0
      [<[PII_REDACTED]f75d85>] orangefs_prepare_debugfs_help_string+0x5e/0x480 [orangefs]
      [<[PII_REDACTED]270a2a>] _sub_I_65535_1+0x57/0xf70 [crc_itu_t]
      [<000000004b1ee1a3>] do_one_initcall+0x87/0x2a0
      [<000000001d0614ae>] do_init_module+0xdf/0x320
      [<00000000efef068c>] load_module+0x2f98/0x3330
      [<[PII_REDACTED]33b44d>] __do_sys_finit_module+0x113/0x1b0
      [<00000000a0da6f99>] do_syscall_64+0x35/0x80
      [<[PII_REDACTED]90b19b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0

When remove the module, should always free debug_help_string. Should
always free the allocated buffer when change the free_debug_help_string.
References: https://git.kernel.org/stable/c/19be31668552a198e887762e25bdcc560800ecb4; https://git.kernel.org/stable/c/2e7c09121064df93c58bbc49d3d0f608d3f584bd; https://git.kernel.org/stable/c/39529b79b023713d4f2d3479dc0ca43ba99df726