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

net: gso: fix panic on frag_list with mixed head alloc types

Since commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat when
splitting gso_size mangled skb having linear-headed frag_list"), it is
allowed to change gso_size of a GRO packet. However, that commit assumes
that "checking the first list_skb member suffices; i.e if either of the
list_skb members have non head_frag head, then the first one has too".

It turns out this assumption does not hold. We've seen BUG_ON being hit
in skb_segment when skbs on the frag_list had differing head_frag with
the vmxnet3 driver. This happens because __netdev_alloc_skb and
__napi_alloc_skb can return a skb that is page backed or kmalloced
depending on the requested size. As the result, the last small skb in
the GRO packet can be kmalloced.

There are three different locations where this can be fixed:

(1) We could check head_frag in GRO and not allow GROing skbs with
    different head_frag. However, that would lead to performance
    regression on normal forward paths with unmodified gso_size, where
    !head_frag in the last packet is not a problem.

(2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating
    that NETIF_F_SG is undesirable. That would need to eat a bit in
    sk_buff. Furthermore, that flag can be unset when all skbs on the
    frag_list are page backed. To retain good performance,
    bpf_skb_net_grow/shrink would have to walk the frag_list.

(3) Walk the frag_list in skb_segment when determining whether
    NETIF_F_SG should be cleared. This of course slows things down.

This patch implements (3). To limit the performance impact in
skb_segment, the list is walked only for skbs with SKB_GSO_DODGY set
that have gso_size changed. Normal paths thus will not hit it.

We could check only the last skb but since we need to walk the whole
list anyway, let's stay on the safe side.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0a9f56e525ea871d3950b90076912f5c7494f00f; https://git.kernel.org/stable/c/50868de7dc4e7f0fcadd6029f32bf4387c102ee6; https://git.kernel.org/stable/c/5876b7f249a1ecbbcc8e35072c3828d6526d1c3a
CVE: CVE-2022-49873
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix wrong reg type conversion in release_reference()

Some helper functions will allocate memory. To avoid memory leaks, the
verifier requires the eBPF program to release these memories by calling
the corresponding helper functions.

When a resource is released, all pointer registers corresponding to the
resource should be invalidated. The verifier use release_references() to
do this job, by apply  __mark_reg_unknown() to each relevant register.

It will give these registers the type of SCALAR_VALUE. A register that
will contain a pointer value at runtime, but of type SCALAR_VALUE, which
may allow the unprivileged user to get a kernel pointer by storing this
register into a map.

Using __mark_reg_not_init() while NOT allow_ptr_leaks can mitigate this
problem.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-704, CWE-704
References: https://git.kernel.org/stable/c/466ce46f251dfb259a8cbaa895ab9edd6fb56240; https://git.kernel.org/stable/c/ae5ccad6c711db0f2ca1231be051935dd128b8f5; https://git.kernel.org/stable/c/cedd4f01f67be94735f15123158f[PII_REDACTED]37
CVE: CVE-2022-49874
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

HID: hyperv: fix possible memory leak in mousevsc_probe()

If hid_add_device() returns error, it should call hid_destroy_device()
to free hid_dev which is allocated in hid_allocate_device().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/249b743801c00542e9324f87b380032e957a43e8; https://git.kernel.org/stable/c/5ad95d71344b7ffec360d62591633b3c465dc049; https://git.kernel.org/stable/c/5f3aba6566b866f5b0a4916f0b2e8a6ae66a6451
CVE: CVE-2022-49875
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

bpftool: Fix NULL pointer dereference when pin {PROG, MAP, LINK} without FILE

When using bpftool to pin {PROG, MAP, LINK} without FILE,
segmentation fault will occur. The reson is that the lack
of FILE will cause strlen to trigger NULL pointer dereference.
The corresponding stacktrace is shown below:

do_pin
  do_pin_any
    do_pin_fd
      mount_bpffs_for_pin
        strlen(name) <- NULL pointer dereference

Fix it by adding validation to the common process.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/34de8e6e0e1f66e431abf4123934a2581cb5f133; https://git.kernel.org/stable/c/6dcdd1b68b7f9333d48d48fc77b75e7f235f6a4a; https://git.kernel.org/stable/c/8c80b2fca4112d724dde477aed13f7b0510a2792
CVE: CVE-2022-49876
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: fix general-protection-fault in ieee80211_subif_start_xmit()

When device is running and the interface status is changed, the gpf issue
is triggered. The problem triggering process is as follows:
Thread A:                           Thread B
ieee80211_runtime_change_iftype()   process_one_work()
    ...                                 ...
    ieee80211_do_stop()                 ...
    ...                                 ...
        sdata->bss = NULL               ...
        ...                             ieee80211_subif_start_xmit()
                                            ieee80211_multicast_to_unicast
                                    //!sdata->bss->multicast_to_unicast
                                      cause gpf issue

When the interface status is changed, the sending queue continues to send
packets. After the bss is set to NULL, the bss is accessed. As a result,
this causes a general-protection-fault issue.

The following is the stack information:
general protection fault, probably for non-canonical address
0xdffffc000000002f: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x[PII_REDACTED]000178-0x[PII_REDACTED]00017f]
Workqueue: mld mld_ifc_work
RIP: 0010:ieee80211_subif_start_xmit+0x25b/0x1310
Call Trace:
<TASK>
dev_hard_start_xmit+0x1be/0x990
__dev_queue_xmit+0x2c9a/0x3b60
ip6_finish_output2+0xf92/0x1520
ip6_finish_output+0x6af/0x11e0
ip6_output+0x1ed/0x540
mld_sendpack+0xa09/0xe70
mld_ifc_work+0x71c/0xdb0
process_one_work+0x9bf/0x1710
worker_thread+0x665/0x1080
kthread+0x2e4/0x3a0
ret_from_fork+0x1f/0x30
</TASK>
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/03eb68c72cee249aeb7af7d04a83c033aca3d6d9; https://git.kernel.org/stable/c/[PII_REDACTED]46e0de2be192ee7fa[PII_REDACTED]b3a
CVE: CVE-2022-49877
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf, sockmap: Fix the sk->sk_forward_alloc warning of sk_stream_kill_queues

When running `test_sockmap` selftests, the following warning appears:

  WARNING: CPU: 2 PID: 197 at net/core/stream.c:205 sk_stream_kill_queues+0xd3/0xf0
  Call Trace:
  <TASK>
  inet_csk_destroy_sock+0x55/0x110
  tcp_rcv_state_process+0xd28/0x1380
  ? tcp_v4_do_rcv+0x77/0x2c0
  tcp_v4_do_rcv+0x77/0x2c0
  __release_sock+0x106/0x130
  __tcp_close+0x1a7/0x4e0
  tcp_close+0x20/0x70
  inet_release+0x3c/0x80
  __sock_release+0x3a/0xb0
  sock_close+0x14/0x20
  __fput+0xa3/0x260
  task_work_run+0x59/0xb0
  exit_to_user_mode_prepare+0x1b3/0x1c0
  syscall_exit_to_user_mode+0x19/0x50
  do_syscall_64+0x48/0x90
  entry_SYSCALL_64_after_hwframe+0x44/0xae

The root case is in commit 84472b436e76 ("bpf, sockmap: Fix more uncharged
while msg has more_data"), where I used msg->sg.size to replace the tosend,
causing breakage:

  if (msg->apply_bytes && msg->apply_bytes < tosend)
    tosend = psock->apply_bytes;
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/14e8bc3bf7bd6af64d7538a0684c8238d96cdfd7; https://git.kernel.org/stable/c/8ec95b94716a1e4d126edc3fb2bc426a717e2dba; https://git.kernel.org/stable/c/95adbd2ac8de82e43fd6b347e7e1b47f74dc1abb
CVE: CVE-2022-49878
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf, verifier: Fix memory leak in array reallocation for stack state

If an error (NULL) is returned by krealloc(), callers of realloc_array()
were setting their allocation pointers to NULL, but on error krealloc()
does not touch the original allocation. This would result in a memory
resource leak. Instead, free the old allocation on the error handling
path.

The memory leak information is as follows as also reported by Zhengchao:

  unreferenced object 0xffff[PII_REDACTED]00 (size 256):
  comm "bpf_repo", pid 6490, jiffies[PII_REDACTED] (age 17.170s)
  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:
    [<00000000b211474b>] __kmalloc_node_track_caller+0x45/0xc0
    [<[PII_REDACTED]712a0b>] krealloc+0x83/0xd0
    [<[PII_REDACTED]9aab02>] realloc_array+0x82/0xe2
    [<00000000b1ca41d1>] grow_stack_state+0xfb/0x186
    [<00000000cd6f36d2>] check_mem_access.cold+0x141/0x1341
    [<[PII_REDACTED]>] do_check_common+0x5358/0xb350
    [<[PII_REDACTED]f6b091>] bpf_check.cold+0xc3/0x29d
    [<[PII_REDACTED]73c690>] bpf_prog_load+0x13db/0x2240
    [<[PII_REDACTED]8d1644>] __sys_bpf+0x1605/0x4ce0
    [<[PII_REDACTED]3f29bd>] __x64_sys_bpf+0x75/0xb0
    [<[PII_REDACTED]fedaf5>] do_syscall_64+0x35/0x80
    [<000000002bd58261>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/06615967d4889b08b19ff3dda96e8b131282f73d; https://git.kernel.org/stable/c/3e210891c4a4c2d858cd6f9f61d5809af251d4df; https://git.kernel.org/stable/c/42378a9ca55347102bbf[PII_REDACTED]1d8fe3ece2
CVE: CVE-2022-49879
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: fix BUG_ON() when directory entry has invalid rec_len

The rec_len field in the directory entry has to be a multiple of 4.  A
corrupted filesystem image can be used to hit a BUG() in
ext4_rec_len_to_disk(), called from make_indexed_dir().

 ------------[ cut here ]------------
 kernel BUG at fs/ext4/ext4.h:2413!
 ...
 RIP: 0010:make_indexed_dir+0x53f/0x5f0
 ...
 Call Trace:
  <TASK>
  ? add_dirent_to_buf+0x1b2/0x200
  ext4_add_entry+0x36e/0x480
  ext4_add_nondir+0x2b/0xc0
  ext4_create+0x163/0x200
  path_openat+0x635/0xe90
  do_filp_open+0xb4/0x160
  ? __create_object.isra.0+0x1de/0x3b0
  ? _raw_spin_unlock+0x12/0x30
  do_sys_openat2+0x91/0x150
  __x64_sys_open+0x6c/0xa0
  do_syscall_64+0x3c/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0

The fix simply adds a call to ext4_check_dir_entry() to validate the
directory entry, returning -EFSCORRUPTED if the entry is invalid.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-617
References: https://git.kernel.org/stable/c/156451a67b93986fb07c274ef6995ff40766c5ad; https://git.kernel.org/stable/c/17a0bc9bd697f75cfdf9b378d5eb2d7409c91340; https://git.kernel.org/stable/c/2fa24d0274fbf913b56ee31f15bc01168669d909
CVE: CVE-2022-49881
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: cfg80211: fix memory leak in query_regdb_file()

In the function query_regdb_file() the alpha2 parameter is duplicated
using kmemdup() and subsequently freed in regdb_fw_cb(). However,
request_firmware_nowait() can fail without calling regdb_fw_cb() and
thus leak memory.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/0ede1a988299e95d54bd89551fd635980572e920; https://git.kernel.org/stable/c/[PII_REDACTED]86330937bcd382a7bc4ccd767383bc; https://git.kernel.org/stable/c/38c9fa2cc6bf4b6e1a74057aef8b5cffd23d3264
CVE: CVE-2022-49882
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: Reject attempts to consume or refresh inactive gfn_to_pfn_cache

Reject kvm_gpc_check() and kvm_gpc_refresh() if the cache is inactive.
Not checking the active flag during refresh is particularly egregious, as
KVM can end up with a valid, inactive cache, which can lead to a variety
of use-after-free bugs, e.g. consuming a NULL kernel pointer or missing
an mmu_notifier invalidation due to the cache not being on the list of
gfns to invalidate.

Note, "active" needs to be set if and only if the cache is on the list
of caches, i.e. is reachable via mmu_notifier events.  If a relevant
mmu_notifier event occurs while the cache is "active" but not on the
list, KVM will not acquire the cache's lock and so will not serailize
the mmu_notifier event with active users and/or kvm_gpc_refresh().

A race between KVM_XEN_ATTR_TYPE_SHARED_INFO and KVM_XEN_HVM_EVTCHN_SEND
can be exploited to trigger the bug.

1. Deactivate shinfo cache:

kvm_xen_hvm_set_attr
case KVM_XEN_ATTR_TYPE_SHARED_INFO
 kvm_gpc_deactivate
  kvm_gpc_unmap
   gpc->valid = false
   gpc->khva = NULL
  gpc->active = false

Result: active = false, valid = false

2. Cause cache refresh:

kvm_arch_vm_ioctl
case KVM_XEN_HVM_EVTCHN_SEND
 kvm_xen_hvm_evtchn_send
  kvm_xen_set_evtchn
   kvm_xen_set_evtchn_fast
    kvm_gpc_check
    return -EWOULDBLOCK because !gpc->valid
   kvm_xen_set_evtchn_fast
    return -EWOULDBLOCK
   kvm_gpc_refresh
    hva_to_pfn_retry
     gpc->valid = true
     gpc->khva = not NULL

Result: active = false, valid = true

3. Race ioctl KVM_XEN_HVM_EVTCHN_SEND against ioctl
KVM_XEN_ATTR_TYPE_SHARED_INFO:

kvm_arch_vm_ioctl
case KVM_XEN_HVM_EVTCHN_SEND
 kvm_xen_hvm_evtchn_send
  kvm_xen_set_evtchn
   kvm_xen_set_evtchn_fast
    read_lock gpc->lock
                                          kvm_xen_hvm_set_attr case
                                          KVM_XEN_ATTR_TYPE_SHARED_INFO
                                           mutex_lock kvm->lock
                                           kvm_xen_shared_info_init
                                            kvm_gpc_activate
                                             gpc->khva = NULL
    kvm_gpc_check
     [ Check passes because gpc->valid is
       still true, even though gpc->khva
       is already NULL. ]
    shinfo = gpc->khva
    pending_bits = shinfo->evtchn_pending
    CRASH: test_and_set_bit(..., pending_bits)
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/bfa9672f8fc9eb118124bab61899d2dd497f95ba; https://git.kernel.org/stable/c/ecbcf030b45666ad11bc98565e71dfbcb7be4393
CVE: CVE-2022-49883
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: smm: number of GPRs in the SMRAM image depends on the image format

On 64 bit host, if the guest doesn't have X86_FEATURE_LM, KVM will
access 16 gprs to 32-bit smram image, causing out-ouf-bound ram
access.

On 32 bit host, the rsm_load_state_64/enter_smm_save_state_64
is compiled out, thus access overflow can't happen.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/696db303e54f7352623d9f640e6c51d8fa9d5588; https://git.kernel.org/stable/c/a7ebfbea0f52550d7cdf12c38f3f5eaa7b2b6494
CVE: CVE-2022-49884
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: Initialize gfn_to_pfn_cache locks in dedicated helper

Move the gfn_to_pfn_cache lock initialization to another helper and
call the new helper during VM/vCPU creation.  There are race
conditions possible due to kvm_gfn_to_pfn_cache_init()'s
ability to re-initialize the cache's locks.

For example: a race between ioctl(KVM_XEN_HVM_EVTCHN_SEND) and
kvm_gfn_to_pfn_cache_init() leads to a corrupted shinfo gpc lock.

                (thread 1)                |           (thread 2)
                                          |
 kvm_xen_set_evtchn_fast                  |
  read_lock_irqsave(&gpc->lock, ...)      |
                                          | kvm_gfn_to_pfn_cache_init
                                          |  rwlock_init(&gpc->lock)
  read_unlock_irqrestore(&gpc->lock, ...) |

Rename "cache_init" and "cache_destroy" to activate+deactivate to
avoid implying that the cache really is destroyed/freed.

Note, there more races in the newly named kvm_gpc_activate() that will
be addressed separately.

[sean: call out that this is a bug fix]
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/52491a38b2c2411f3f0229dc6ad610349c704a41; https://git.kernel.org/stable/c/61242001d6c9c253df7645dab090842d8da08764
CVE: CVE-2022-49885
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ACPI: APEI: Fix integer overflow in ghes_estatus_pool_init()

Change num_ghes from int to unsigned int, preventing an overflow
and causing subsequent vmalloc() to fail.

The overflow happens in ghes_estatus_pool_init() when calculating
len during execution of the statement below as both multiplication
operands here are signed int:

len += (num_ghes * GHES_ESOURCE_PREALLOC_MAX_SIZE);

The following call trace is observed because of this bug:

[    9.317108] swapper/0: vmalloc error: size[PII_REDACTED][PII_REDACTED], exceeds total pages, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0-1
[    9.317131] Call Trace:
[    9.317134]  <TASK>
[    9.317137]  dump_stack_lvl+0x49/0x5f
[    9.317145]  dump_stack+0x10/0x12
[    9.317146]  warn_alloc.cold+0x7b/0xdf
[    9.317150]  ? __device_attach+0x16a/0x1b0
[    9.317155]  __vmalloc_node_range+0x702/0x740
[    9.317160]  ? device_add+0x17f/0x920
[    9.317164]  ? dev_set_name+0x53/0x70
[    9.317166]  ? platform_device_add+0xf9/0x240
[    9.317168]  __vmalloc_node+0x49/0x50
[    9.317170]  ? ghes_estatus_pool_init+0x43/0xa0
[    9.317176]  vmalloc+0x21/0x30
[    9.317177]  ghes_estatus_pool_init+0x43/0xa0
[    9.317179]  acpi_hest_init+0x129/0x19c
[    9.317185]  acpi_init+0x434/0x4a4
[    9.317188]  ? acpi_sleep_proc_init+0x2a/0x2a
[    9.317190]  do_one_initcall+0x48/0x200
[    9.317195]  kernel_init_freeable+0x221/0x284
[    9.317200]  ? rest_init+0xe0/0xe0
[    9.317204]  kernel_init+0x1a/0x130
[    9.317205]  ret_from_fork+0x22/0x30
[    9.317208]  </TASK>

[ rjw: Subject and changelog edits ]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190, CWE-190
References: https://git.kernel.org/stable/c/43d2748394c3feb86c0c771466f5847e274fc043; https://git.kernel.org/stable/c/4c10c854113720cbfe75d4f51db79b700a629e73; https://git.kernel.org/stable/c/9edf20e5a1d805855e78f241cf221d741b50d482
CVE: CVE-2022-49886
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/tdx: Panic on bad configs that #VE on "private" memory access

All normal kernel memory is "TDX private memory".  This includes
everything from kernel stacks to kernel text.  Handling
exceptions on arbitrary accesses to kernel memory is essentially
impossible because they can happen in horribly nasty places like
kernel entry/exit.  But, TDX hardware can theoretically _deliver_
a virtualization exception (#VE) on any access to private memory.

But, it's not as bad as it sounds.  TDX can be configured to never
deliver these exceptions on private memory with a "TD attribute"
called ATTR_SEPT_VE_DISABLE.  The guest has no way to *set* this
attribute, but it can check it.

Ensure ATTR_SEPT_VE_DISABLE is set in early boot.  panic() if it
is unset.  There is no sane way for Linux to run with this
attribute clear so a panic() is appropriate.

There's small window during boot before the check where kernel
has an early #VE handler. But the handler is only for port I/O
and will also panic() as soon as it sees any other #VE, such as
a one generated by a private memory access.

[ dhansen: Rewrite changelog and rebase on new tdx_parse_tdinfo().
	   Add Kirill's tested-by because I made changes since
	   he wrote this. ]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/373e715e31bf4e0f129befe87613a278fac228d3; https://git.kernel.org/stable/c/895c168c8f78079f21ad50fead7593ffa352f795
CVE: CVE-2022-49887
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

media: meson: vdec: fix possible refcount leak in vdec_probe()

v4l2_device_unregister need to be called to put the refcount got by
v4l2_device_register when vdec_probe fails or vdec_remove is called.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0457e7b12ece1a7e41fa0ae8b7e47c0a72a83bef; https://git.kernel.org/stable/c/[PII_REDACTED]1a0be3b95bec2e1ba714673e90feba; https://git.kernel.org/stable/c/[PII_REDACTED]234d9cc6a11b4641bb773928f1390f
CVE: CVE-2022-49889
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ring-buffer: Check for NULL cpu_buffer in ring_buffer_wake_waiters()

On some machines the number of listed CPUs may be bigger than the actual
CPUs that exist. The tracing subsystem allocates a per_cpu directory with
access to the per CPU ring buffer via a cpuX file. But to save space, the
ring buffer will only allocate buffers for online CPUs, even though the
CPU array will be as big as the nr_cpu_ids.

With the addition of waking waiters on the ring buffer when closing the
file, the ring_buffer_wake_waiters() now needs to make sure that the
buffer is allocated (with the irq_work allocated with it) before trying to
wake waiters, as it will cause a NULL pointer dereference.

While debugging this, I added a NULL check for the buffer itself (which is
OK to do), and also NULL pointer checks against buffer->buffers (which is
not fine, and will WARN) as well as making sure the CPU number passed in
is within the nr_cpu_ids (which is also not fine if it isn't).


Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1204705
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/49ca992f6e50d0f46ec9608f44e011cf3121f389; https://git.kernel.org/stable/c/7433632c9ff68a991bd0bc38cabf354e9d2de410; https://git.kernel.org/stable/c/b5074df412bf3df9d6ce096b6fa03eb1082d05c9
CVE: CVE-2022-49890
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

capabilities: fix potential memleak on error path from vfs_getxattr_alloc()

In cap_inode_getsecurity(), we will use vfs_getxattr_alloc() to
complete the memory allocation of tmpbuf, if we have completed
the memory allocation of tmpbuf, but failed to call handler->get(...),
there will be a memleak in below logic:

  |-- ret = (int)vfs_getxattr_alloc(mnt_userns, ...)
    |           /* ^^^ alloc for tmpbuf */
    |-- value = krealloc(*xattr_value, error + 1, flags)
    |           /* ^^^ alloc memory */
    |-- error = handler->get(handler, ...)
    |           /* error! */
    |-- *xattr_value = value
    |           /* xattr_value is &tmpbuf (memory leak!) */

So we will try to free(tmpbuf) after vfs_getxattr_alloc() fails to fix it.

[PM: subject line and backtrace tweaks]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/0c3e6288da650d1ec911a259c77bc2d88e498603; https://git.kernel.org/stable/c/2de8eec8afb75792440b8900a01d52b8f6742fd1; https://git.kernel.org/stable/c/6bb00eb21c0fbf18e5d3538c9ff0cf63fd0ace85