deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-49546
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/kexec: fix memory leak of elf header buffer

This is reported by kmemleak detector:

unreferenced object 0xffffc900002a9000 (size 4096):
  comm "kexec", pid 14950, jiffies[PII_REDACTED] (age 373.951s)
  hex dump (first 32 bytes):
    7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00  .ELF............
    04 00 3e 00 01 00 00 00 00 00 00 00 00 00 00 00  ..>.............
  backtrace:
    [<[PII_REDACTED]a8ef9f>] __vmalloc_node_range+0x101/0x170
    [<000000002b66b6c0>] __vmalloc_node+0xb4/0x160
    [<00000000ad40107d>] crash_prepare_elf64_headers+0x8e/0xcd0
    [<[PII_REDACTED]afff23>] crash_load_segments+0x260/0x470
    [<[PII_REDACTED]ebe95c>] bzImage64_load+0x814/0xad0
    [<[PII_REDACTED]e16b05>] arch_kexec_kernel_image_load+0x1be/0x2a0
    [<000000009ef2fc88>] kimage_file_alloc_init+0x2ec/0x5a0
    [<[PII_REDACTED]f5a97a>] __do_sys_kexec_file_load+0x28d/0x530
    [<[PII_REDACTED]c19992>] do_syscall_64+0x3b/0x90
    [<[PII_REDACTED]e063a4>] entry_SYSCALL_64_after_hwframe+0x44/0xae

In crash_prepare_elf64_headers(), a buffer is allocated via vmalloc() to
store elf headers.  While it's not freed back to system correctly when
kdump kernel is reloaded or unloaded.  Then memory leak is caused.  Fix it
by introducing x86 specific function arch_kimage_file_post_load_cleanup(),
and freeing the buffer there.

And also remove the incorrect elf header buffer freeing code.  Before
calling arch specific kexec_file loading function, the image instance has
been initialized.  So 'image->elf_headers' must be NULL.  It doesn't make
sense to free the elf header buffer in the place.

Three different people have reported three bugs about the memory leak on
x86_64 inside Redhat.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/115ee42a4c2f26ba2b4ace2668a3f004621f6833; https://git.kernel.org/stable/c/23cf39dccf[PII_REDACTED]a6f39b119e9116a27f1a; https://git.kernel.org/stable/c/8765a423a87d74ef24ea02b43b2728fe4039f248
CVE: CVE-2022-49548
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix potential array overflow in bpf_trampoline_get_progs()

The cnt value in the 'cnt >= BPF_MAX_TRAMP_PROGS' check does not
include BPF_TRAMP_MODIFY_RETURN bpf programs, so the number of
the attached BPF_TRAMP_MODIFY_RETURN bpf programs in a trampoline
can exceed BPF_MAX_TRAMP_PROGS.

When this happens, the assignment '*progs++ = aux->prog' in
bpf_trampoline_get_progs() will cause progs array overflow as the
progs field in the bpf_tramp_progs struct can only hold at most
BPF_MAX_TRAMP_PROGS bpf programs.
CVSS Score: 7.8 (HIGH)
CWE: CWE-129, CWE-129
References: https://git.kernel.org/stable/c/32c4559c61652f24c9fdd[PII_REDACTED]fe37453bc; https://git.kernel.org/stable/c/4f8897bcc20b9ae44758e0572538d741ab66f0dc; https://git.kernel.org/stable/c/7f845de2863334bed4f362e95853f5e7bc323737
CVE: CVE-2022-49549
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/MCE/AMD: Fix memory leak when threshold_create_bank() fails

In mce_threshold_create_device(), if threshold_create_bank() fails, the
previously allocated threshold banks array @bp will be leaked because
the call to mce_threshold_remove_device() will not free it.

This happens because mce_threshold_remove_device() fetches the pointer
through the threshold_banks per-CPU variable but bp is written there
only after the bank creation is successful, and not before, when
threshold_create_bank() fails.

Add a helper which unwinds all the bank creation work previously done
and pass into it the previously allocated threshold banks array for
freeing.

  [ bp: Massage. ]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/396b8e7ab2a99ddac57d3522b3da5e58cb608d37; https://git.kernel.org/stable/c/9708f1956eeb70c86943e0bc62fa3b0101b59616; https://git.kernel.org/stable/c/b4acb8e7f1594607bc9017ef0aacb40b24a003d6
CVE: CVE-2022-49550
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: provide block_invalidate_folio to fix memory leak

The ntfs3 filesystem lacks the 'invalidate_folio' method and it causes
memory leak. If you write to the filesystem and then unmount it, the
cached written data are not freed and they are permanently leaked.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/0753245a72ec[PII_REDACTED]6499ee2e0919164b3f; https://git.kernel.org/stable/c/724bbe49c5e427cb077357d72d240a649f2e4054
CVE: CVE-2022-49551
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: isp1760: Fix out-of-bounds array access

Running the driver through kasan gives an interesting splat:

  BUG: KASAN: global-out-of-bounds in isp1760_register+0x180/0x70c
  Read of size 20 at addr f1db2e64 by task swapper/0/1
  (...)
  isp1760_register from isp1760_plat_probe+0x1d8/0x220
  (...)

This happens because the loop reading the regmap fields for the
different ISP1760 variants look like this:

  for (i = 0; i < HC_FIELD_MAX; i++) { ... }

Meaning it expects the arrays to be at least HC_FIELD_MAX - 1 long.

However the arrays isp1760_hc_reg_fields[], isp1763_hc_reg_fields[],
isp1763_hc_volatile_ranges[] and isp1763_dc_volatile_ranges[] are
dynamically sized during compilation.

Fix this by putting an empty assignment to the [HC_FIELD_MAX]
and [DC_FIELD_MAX] array member at the end of each array.
This will make the array one member longer than it needs to be,
but avoids the risk of overwriting whatever is inside
[HC_FIELD_MAX - 1] and is simple and intuitive to read. Also
add comments explaining what is going on.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125, CWE-125
References: https://git.kernel.org/stable/c/26ae2c942b5702f2e43d36b2a4389cfb7d616b6a; https://git.kernel.org/stable/c/463bddd3ff1acf4036ddb80c34a715eb99debf46; https://git.kernel.org/stable/c/47d39cb57e8669e507d17d9e0d067d2b3e3a87ae
CVE: CVE-2022-49552
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix combination of jit blinding and pointers to bpf subprogs.

The combination of jit blinding and pointers to bpf subprogs causes:
[   36.989548] BUG: unable to handle page fault for address: [PII_REDACTED]
[   36.990342] #PF: supervisor instruction fetch in kernel mode
[   36.990968] #PF: error_code(0x0010) - not-present page
[   36.994859] RIP: 0010:0x100000001
[   36.995209] Code: Unable to access opcode bytes at RIP 0xffffffd7.
[   37.004091] Call Trace:
[   37.004351]  <TASK>
[   37.004576]  ? bpf_loop+0x4d/0x70
[   37.004932]  ? bpf_prog_3899083f75e4c5de_F+0xe3/0x13b

The jit blinding logic didn't recognize that ld_imm64 with an address
of bpf subprogram is a special instruction and proceeded to randomize it.
By itself it wouldn't have been an issue, but jit_subprogs() logic
relies on two step process to JIT all subprogs and then JIT them
again when addresses of all subprogs are known.
Blinding process in the first JIT phase caused second JIT to miss
adjustment of special ld_imm64.

Fix this issue by ignoring special ld_imm64 instructions that don't have
user controlled constants and shouldn't be blinded.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/4b6313cf99b0d51b49aeaea98ec76ca8161ecb80; https://git.kernel.org/stable/c/a029b02b47dd5bb87a21550d9d9a80cb4dd3f714; https://git.kernel.org/stable/c/d106a3e96fca30e44081eae9c27aab28fc132a46
CVE: CVE-2022-49553
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: validate BOOT sectors_per_clusters

When the NTFS BOOT sectors_per_clusters field is > 0x80, it represents a
shift value.  Make sure that the shift value is not too large before using
it (NTFS max cluster size is 2MB).  Return -EVINVAL if it too large.

This prevents negative shift values and shift values that are larger than
the field size.

Prevents this UBSAN error:

 UBSAN: shift-out-of-bounds in ../fs/ntfs3/super.c:673:16
 shift exponent -192 is negative
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190
References: https://git.kernel.org/stable/c/4746c49b11b2403f5b5b07c6eac9e60663dcd9a3; https://git.kernel.org/stable/c/58cf68a1886d14ffdc5c892ce483a82156769e88; https://git.kernel.org/stable/c/a2b6986316a2d106f6951e76db70fa4b2fde64a9
CVE: CVE-2022-49554
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

zsmalloc: fix races between asynchronous zspage free and page migration

The asynchronous zspage free worker tries to lock a zspage's entire page
list without defending against page migration.  Since pages which haven't
yet been locked can concurrently migrate off the zspage page list while
lock_zspage() churns away, lock_zspage() can suffer from a few different
lethal races.

It can lock a page which no longer belongs to the zspage and unsafely
dereference page_private(), it can unsafely dereference a torn pointer to
the next page (since there's a data race), and it can observe a spurious
NULL pointer to the next page and thus not lock all of the zspage's pages
(since a single page migration will reconstruct the entire page list, and
create_page_chain() unconditionally zeroes out each list pointer in the
process).

Fix the races by using migrate_read_lock() in lock_zspage() to synchronize
with page migration.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/2505a981114dcb715f8977b8433f[PII_REDACTED]d8; https://git.kernel.org/stable/c/3674d8a8dadd03a447dd21069d4dacfc3399b63b; https://git.kernel.org/stable/c/3ec459c8810e658401be428d3168eacfc380bdd0
CVE: CVE-2022-49555
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_qca: Use del_timer_sync() before freeing

While looking at a crash report on a timer list being corrupted, which
usually happens when a timer is freed while still active. This is
commonly triggered by code calling del_timer() instead of
del_timer_sync() just before freeing.

One possible culprit is the hci_qca driver, which does exactly that.

Eric mentioned that wake_retrans_timer could be rearmed via the work
queue, so also move the destruction of the work queue before
del_timer_sync().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2717654ae022e6ea959a4b7b762702fe1a4690c2; https://git.kernel.org/stable/c/37d17f63d085d601011964ade7371aeebeb6ed4b; https://git.kernel.org/stable/c/4989bb03342941f2b730b37dfa38bce27b543661
CVE: CVE-2022-49556
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: SVM: Use kzalloc for sev ioctl interfaces to prevent kernel data leak

For some sev ioctl interfaces, the length parameter that is passed maybe
less than or equal to SEV_FW_BLOB_MAX_SIZE, but larger than the data
that PSP firmware returns. In this case, kmalloc will allocate memory
that is the size of the input rather than the size of the data.
Since PSP firmware doesn't fully overwrite the allocated buffer, these
sev ioctl interface may return uninitialized kernel slab memory.
CVSS Score: 7.1 (HIGH)
References: https://git.kernel.org/stable/c/401bef1f95de92c3a8c6eece46e02fa88d7285ee; https://git.kernel.org/stable/c/57a01725339f9d82b099102ba2751621b1caab93; https://git.kernel.org/stable/c/bbdcc644b59e01e98c68894a9fab42b9687f42b0
CVE: CVE-2022-49558
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: double hook unregistration in netns path

__nft_release_hooks() is called from pre_netns exit path which
unregisters the hooks, then the NETDEV_UNREGISTER event is triggered
which unregisters the hooks again.

[  565.221461] WARNING: CPU: 18 PID: 193 at net/netfilter/core.c:495 __nf_unregister_net_hook+0x247/0x270
[...]
[  565.246890] CPU: 18 PID: 193 Comm: kworker/u64:1 Tainted: G            E     5.18.0-rc7+ #27
[  565.253682] Workqueue: netns cleanup_net
[  565.257059] RIP: 0010:__nf_unregister_net_hook+0x247/0x270
[...]
[  565.297120] Call Trace:
[  565.300900]  <TASK>
[  565.304683]  nf_tables_flowtable_event+0x16a/0x220 [nf_tables]
[  565.308518]  raw_notifier_call_chain+0x63/0x80
[  565.312386]  unregister_netdevice_many+0x54f/0xb50

Unregister and destroy netdev hook from netns pre_exit via kfree_rcu
so the NETDEV_UNREGISTER path see unregistered hooks.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3fac8ce48fa9fd61ee9056d3ed48b2edefca8b82; https://git.kernel.org/stable/c/86c0154f4c3a56c5db8b9dd09e3ce885382c2c19; https://git.kernel.org/stable/c/9c413a8c8bb49cc[PII_REDACTED]ecb260e885bb2b
CVE: CVE-2022-49559
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: Drop WARNs that assert a triple fault never "escapes" from L2

Remove WARNs that sanity check that KVM never lets a triple fault for L2
escape and incorrectly end up in L1.  In normal operation, the sanity
check is perfectly valid, but it incorrectly assumes that it's impossible
for userspace to induce KVM_REQ_TRIPLE_FAULT without bouncing through
KVM_RUN (which guarantees kvm_check_nested_state() will see and handle
the triple fault).

The WARN can currently be triggered if userspace injects a machine check
while L2 is active and CR4.MCE=0.  And a future fix to allow save/restore
of KVM_REQ_TRIPLE_FAULT, e.g. so that a synthesized triple fault isn't
lost on migration, will make it trivially easy for userspace to trigger
the WARN.

Clearing KVM_REQ_TRIPLE_FAULT when forcibly leaving guest mode is
tempting, but wrong, especially if/when the request is saved/restored,
e.g. if userspace restores events (including a triple fault) and then
restores nested state (which may forcibly leave guest mode).  Ignoring
the fact that KVM doesn't currently provide the necessary APIs, it's
userspace's responsibility to manage pending events during save/restore.

  ------------[ cut here ]------------
  WARNING: CPU: 7 PID: 1399 at arch/x86/kvm/vmx/nested.c:4522 nested_vmx_vmexit+0x7fe/0xd90 [kvm_intel]
  Modules linked in: kvm_intel kvm irqbypass
  CPU: 7 PID: 1399 Comm: state_test Not tainted 5.17.0-rc3+ #808
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
  RIP: 0010:nested_vmx_vmexit+0x7fe/0xd90 [kvm_intel]
  Call Trace:
   <TASK>
   vmx_leave_nested+0x30/0x40 [kvm_intel]
   vmx_set_nested_state+0xca/0x3e0 [kvm_intel]
   kvm_arch_vcpu_ioctl+0xf49/0x13e0 [kvm]
   kvm_vcpu_ioctl+0x4b9/0x660 [kvm]
   __x64_sys_ioctl+0x83/0xb0
   do_syscall_64+0x3b/0xc0
   entry_SYSCALL_64_after_hwframe+0x44/0xae
   </TASK>
  ---[ end trace [PII_REDACTED] ]---
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/45846661d10422ce9e22da21f8277540b29eca22; https://git.kernel.org/stable/c/7de373c9b48229e428ecdb8fbde269c5a8617fd2; https://git.kernel.org/stable/c/8d3a2aa0976f57320ba89baf9d57fb158dd0cd0d
CVE: CVE-2022-49560
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

exfat: check if cluster num is valid

Syzbot reported slab-out-of-bounds read in exfat_clear_bitmap.
This was triggered by reproducer calling truncute with size 0,
which causes the following trace:

BUG: KASAN: slab-out-of-bounds in exfat_clear_bitmap+0x147/0x490 fs/exfat/balloc.c:174
Read of size 8 at addr ffff888115aa9508 by task syz-executor251/365

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack_lvl+0x1e2/0x24b lib/dump_stack.c:118
 print_address_description+0x81/0x3c0 mm/kasan/report.c:233
 __kasan_report mm/kasan/report.c:419 [inline]
 kasan_report+0x1a4/0x1f0 mm/kasan/report.c:436
 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:309
 exfat_clear_bitmap+0x147/0x490 fs/exfat/balloc.c:174
 exfat_free_cluster+0x25a/0x4a0 fs/exfat/fatent.c:181
 __exfat_truncate+0x99e/0xe00 fs/exfat/file.c:217
 exfat_truncate+0x11b/0x4f0 fs/exfat/file.c:243
 exfat_setattr+0xa03/0xd40 fs/exfat/file.c:339
 notify_change+0xb76/0xe10 fs/attr.c:336
 do_truncate+0x1ea/0x2d0 fs/open.c:65

Move the is_valid_cluster() helper from fatent.c to a common
header to make it reusable in other *.c files. And add is_valid_cluster()
to validate if cluster number is within valid range in exfat_clear_bitmap()
and exfat_set_bitmap().
CVSS Score: 7.1 (HIGH)
CWE: CWE-125, CWE-125
References: https://git.kernel.org/stable/c/[PII_REDACTED]df2d9c53294f7a858d5e6fd7346e08; https://git.kernel.org/stable/c/64ba4b15e5c045f8b746c6da5fc9be9a6b00b61d; https://git.kernel.org/stable/c/7c58b14b6f9cde9f69e7fa053ab73f6e013a7131
CVE: CVE-2022-49561
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: conntrack: re-fetch conntrack after insertion

In case the conntrack is clashing, insertion can free skb->_nfct and
set skb->_nfct to the already-confirmed entry.

This wasn't found before because the conntrack entry and the extension
space used to free'd after an rcu grace period, plus the race needs
events enabled to trigger.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/01989d7eebb61c99bd4b88ebc8e261bd2f02caed; https://git.kernel.org/stable/c/04e4a11dc723c52db7a36dc58f0d69ce6426f8f0; https://git.kernel.org/stable/c/04f9e9104c969d8ce10a4a43634f641ed082092d
CVE: CVE-2022-49562
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: Use __try_cmpxchg_user() to update guest PTE A/D bits

Use the recently introduced __try_cmpxchg_user() to update guest PTE A/D
bits instead of mapping the PTE into kernel address space.  The VM_PFNMAP
path is broken as it assumes that vm_pgoff is the base pfn of the mapped
VMA range, which is conceptually wrong as vm_pgoff is the offset relative
to the file and has nothing to do with the pfn.  The horrific hack worked
for the original use case (backing guest memory with /dev/mem), but leads
to accessing "random" pfns for pretty much any other VM_PFNMAP case.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/38b888911e8dc89b89d8147cfb1d2dbe6373bf78; https://git.kernel.org/stable/c/8089e5e1d18402fb8152d6b6815450a36fffa9b0; https://git.kernel.org/stable/c/f122dfe4476890d60b8c679128cd2259ec96a24c
CVE: CVE-2022-49563
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: qat - add param check for RSA

Reject requests with a source buffer that is bigger than the size of the
key. This is to prevent a possible integer underflow that might happen
when copying the source scatterlist into a linear buffer.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-191, CWE-191
References: https://git.kernel.org/stable/c/4d6d2adce08788b7667a6e58002682ea1bbf6a79; https://git.kernel.org/stable/c/[PII_REDACTED]b8b24b8afb31b8eb4df977c63f19c4; https://git.kernel.org/stable/c/f993321e50ba7a8ba4f5b19939e1772a921a1c42
CVE: CVE-2022-49564
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: qat - add param check for DH

Reject requests with a source buffer that is bigger than the size of the
key. This is to prevent a possible integer underflow that might happen
when copying the source scatterlist into a linear buffer.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-191, CWE-191
References: https://git.kernel.org/stable/c/2acbb8771f6ac82422886e63832ee7a0f4b1635b; https://git.kernel.org/stable/c/76c9216833e7c20a67c987cf89719a3f01666aaa; https://git.kernel.org/stable/c/e7f979ed51f[PII_REDACTED]7df663c835b17db1e30
CVE: CVE-2022-49565
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

perf/x86/intel/lbr: Fix unchecked MSR access error on HSW

The fuzzer triggers the below trace.

[ 7763.384369] unchecked MSR access error: WRMSR to 0x689
(tried to write 0x1fffffff8101349e) at rIP: 0xffffffff810704a4
(native_write_msr+0x4/0x20)
[ 7763.397420] Call Trace:
[ 7763.399881]  <TASK>
[ 7763.401994]  intel_pmu_lbr_restore+0x9a/0x1f0
[ 7763.406363]  intel_pmu_lbr_sched_task+0x91/0x1c0
[ 7763.410992]  __perf_event_task_sched_in+0x1cd/0x240

On a machine with the LBR format LBR_FORMAT_EIP_FLAGS2, when the TSX is
disabled, a TSX quirk is required to access LBR from registers.
The lbr_from_signext_quirk_needed() is introduced to determine whether
the TSX quirk should be applied. However, the
lbr_from_signext_quirk_needed() is invoked before the
intel_pmu_lbr_init(), which parses the LBR format information. Without
the correct LBR format information, the TSX quirk never be applied.

Move the lbr_from_signext_quirk_needed() into the intel_pmu_lbr_init().
Checking x86_pmu.lbr_has_tsx in the lbr_from_signext_quirk_needed() is
not required anymore.

Both LBR_FORMAT_EIP_FLAGS2 and LBR_FORMAT_INFO have LBR_TSX flag, but
only the LBR_FORMAT_EIP_FLAGS2 requirs the quirk. Update the comments
accordingly.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/625bcd0685a1612225df83468c83412fc0edb3d7; https://git.kernel.org/stable/c/b0380e13502adf7dd8be4c47d622c3522aae6c63
CVE: CVE-2022-49566
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: qat - fix memory leak in RSA

When an RSA key represented in form 2 (as defined in PKCS #1 V2.1) is
used, some components of the private key persist even after the TFM is
released.
Replace the explicit calls to free the buffers in qat_rsa_exit_tfm()
with a call to qat_rsa_clear_ctx() which frees all buffers referenced in
the TFM context.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/0f967fdc09955221a1951a279481b0bf4d359941; https://git.kernel.org/stable/c/80a52e1ee7757b742f96bfb0d58f0c14eb6583d0; https://git.kernel.org/stable/c/a843925e0287eebb4aa808666bf22c664dfe4c53
CVE: CVE-2022-49568
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: Don't null dereference ops->destroy

A KVM device cleanup happens in either of two callbacks:
1) destroy() which is called when the VM is being destroyed;
2) release() which is called when a device fd is closed.

Most KVM devices use 1) but Book3s's interrupt controller KVM devices
(XICS, XIVE, XIVE-native) use 2) as they need to close and reopen during
the machine execution. The error handling in kvm_ioctl_create_device()
assumes destroy() is always defined which leads to NULL dereference as
discovered by Syzkaller.

This adds a checks for destroy!=NULL and adds a missing release().

This is not changing kvm_destroy_devices() as devices with defined
release() should have been removed from the KVM devices list by then.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/170465715a60cbb7876e6b961b21bd3225469da8; https://git.kernel.org/stable/c/3616776bc51cd3262bb1be60cc01c72e0a1959cf; https://git.kernel.org/stable/c/d4a5a79b780891c5cbdfdc6124d46fdf8d13dba1
CVE: CVE-2022-49569
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

spi: bcm2835: bcm2835_spi_handle_err(): fix NULL pointer deref for non DMA transfers

In case a IRQ based transfer times out the bcm2835_spi_handle_err()
function is called. Since commit 1513ceee70f2 ("spi: bcm2835: Drop
dma_pending flag") the TX and RX DMA transfers are unconditionally
canceled, leading to NULL pointer derefs if ctlr->dma_tx or
ctlr->dma_rx are not set.

Fix the NULL pointer deref by checking that ctlr->dma_tx and
ctlr->dma_rx are valid pointers before accessing them.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/49ffa473218012e765682343de2052eb4c1f06a7; https://git.kernel.org/stable/c/4ceaa684459d414992acbefb4e4c31f2dfc50641; https://git.kernel.org/stable/c/58466e05390043d2805685c70f55f3f59711bdf2