deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-49986
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: storvsc: Remove WQ_MEM_RECLAIM from storvsc_error_wq

storvsc_error_wq workqueue should not be marked as WQ_MEM_RECLAIM as it
doesn't need to make forward progress under memory pressure.  Marking this
workqueue as WQ_MEM_RECLAIM may cause deadlock while flushing a
non-WQ_MEM_RECLAIM workqueue.  In the current state it causes the following
warning:

[   14.506347] ------------[ cut here ]------------
[   14.506354] workqueue: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remove_lun is flushing !WQ_MEM_RECLAIM events_freezable_power_:disk_events_workfn
[   14.506360] WARNING: CPU: 0 PID: 8 at <-snip->kernel/workqueue.c:2623 check_flush_dependency+0xb5/0x130
[   14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 Not tainted 5.4.0-1086-azure #91~18.04.1-Ubuntu
[   14.506391] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022
[   14.506393] Workqueue: storvsc_error_wq_0 storvsc_remove_lun
[   14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130
		<-snip->
[   14.506408] Call Trace:
[   14.506412]  __flush_work+0xf1/0x1c0
[   14.506414]  __cancel_work_timer+0x12f/0x1b0
[   14.506417]  ? kernfs_put+0xf0/0x190
[   14.506418]  cancel_delayed_work_sync+0x13/0x20
[   14.506420]  disk_block_events+0x78/0x80
[   14.506421]  del_gendisk+0x3d/0x2f0
[   14.506423]  sr_remove+0x28/0x70
[   14.506427]  device_release_driver_internal+0xef/0x1c0
[   14.506428]  device_release_driver+0x12/0x20
[   14.506429]  bus_remove_device+0xe1/0x150
[   14.506431]  device_del+0x167/0x380
[   14.506432]  __scsi_remove_device+0x11d/0x150
[   14.506433]  scsi_remove_device+0x26/0x40
[   14.506434]  storvsc_remove_lun+0x40/0x60
[   14.506436]  process_one_work+0x209/0x400
[   14.506437]  worker_thread+0x34/0x400
[   14.506439]  kthread+0x121/0x140
[   14.506440]  ? process_one_work+0x400/0x400
[   14.506441]  ? kthread_park+0x90/0x90
[   14.506443]  ret_from_fork+0x35/0x40
[   14.506445] ---[ end trace 2d9633159fdc6ee7 ]---
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/46fcb0fc884db78a0384be92cc2a51927e6581b8; https://git.kernel.org/stable/c/828f57ac75eaccd6607ee4d1468d34e983e32c68; https://git.kernel.org/stable/c/b4c928ace9a123629eeb14ec5d7ee8f73e5ac668
CVE: CVE-2022-49987
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

md: call __md_stop_writes in md_stop

From the link [1], we can see raid1d was running even after the path
raid_dtr -> md_stop -> __md_stop.

Let's stop write first in destructor to align with normal md-raid to
fix the KASAN issue.

[1]. https://lore.kernel.org/linux-raid/CAPhsuW5gc4AakdGNdF8ubpezAuDLFOYUO_sfMZcec6hQFm8nhg@mail.gmail.com/T/#m7f12bf90481c02c6d2da68c64aeed4779b7df74a
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0dd84b319352bb8ba64752d4e45396d8b13e6018; https://git.kernel.org/stable/c/1678ca35b80a94d474fdc31e2497ce5d7ed52512; https://git.kernel.org/stable/c/661c01b2181d9413c799127f13143583b69f20fd
CVE: CVE-2022-49988
Published: 2025-06-18
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2022-49989
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

xen/privcmd: fix error exit of privcmd_ioctl_dm_op()

The error exit of privcmd_ioctl_dm_op() is calling unlock_pages()
potentially with pages being NULL, leading to a NULL dereference.

Additionally lock_pages() doesn't check for pin_user_pages_fast()
having been completely successful, resulting in potentially not
locking all pages into memory. This could result in sporadic failures
when using the related memory in user mode.

Fix all of that by calling unlock_pages() always with the real number
of pinned pages, which will be zero in case pages being NULL, and by
checking the number of pages pinned by pin_user_pages_fast() matching
the expected number of pages.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/45d47bd9b96e7874b98dbcc7602fe2826c5d62a6; https://git.kernel.org/stable/c/6de50db104af0dc921f593fd95c55db86a52ceef; https://git.kernel.org/stable/c/c2b7bae7c90051fd6a679d5dee00400d67ebbf4a
CVE: CVE-2022-49990
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

s390: fix double free of GS and RI CBs on fork() failure

The pointers for guarded storage and runtime instrumentation control
blocks are stored in the thread_struct of the associated task. These
pointers are initially copied on fork() via arch_dup_task_struct()
and then cleared via copy_thread() before fork() returns. If fork()
happens to fail after the initial task dup and before copy_thread(),
the newly allocated task and associated thread_struct memory are
freed via free_task() -> arch_release_task_struct(). This results in
a double free of the guarded storage and runtime info structs
because the fields in the failed task still refer to memory
associated with the source task.

This problem can manifest as a BUG_ON() in set_freepointer() (with
CONFIG_SLAB_FREELIST_HARDENED enabled) or KASAN splat (if enabled)
when running trinity syscall fuzz tests on s390x. To avoid this
problem, clear the associated pointer fields in
arch_dup_task_struct() immediately after the new task is copied.
Note that the RI flag is still cleared in copy_thread() because it
resides in thread stack memory and that is where stack info is
copied.
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/13cccafe0edcd03bf1c841de8ab8a1c8e34f77d9; https://git.kernel.org/stable/c/25a95303b9e513cd2978aacc385d06e6fec23d07; https://git.kernel.org/stable/c/297ae7e87a87a001dd3dfeac1cb26a42fd929708
CVE: CVE-2022-49991
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/hugetlb: avoid corrupting page->mapping in hugetlb_mcopy_atomic_pte

In MCOPY_ATOMIC_CONTINUE case with a non-shared VMA, pages in the page
cache are installed in the ptes.  But hugepage_add_new_anon_rmap is called
for them mistakenly because they're not vm_shared.  This will corrupt the
page->mapping used by page cache code.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3ada1b3e58db255a14ec73a59d7913e84dc5a8a4; https://git.kernel.org/stable/c/ab74ef708dc51df7cf2b8a890b9c6990fac5c0c6; https://git.kernel.org/stable/c/da60ddd80d09f8371fbba1a238a4b318d13ba698
CVE: CVE-2022-49992
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/mprotect: only reference swap pfn page if type match

Yu Zhao reported a bug after the commit "mm/swap: Add swp_offset_pfn() to
fetch PFN from swap entry" added a check in swp_offset_pfn() for swap type [1]:

  kernel BUG at include/linux/swapops.h:117!
  CPU: 46 PID: 5245 Comm: EventManager_De Tainted: G S         O L 6.0.0-dbg-DEV #2
  RIP: 0010:pfn_swap_entry_to_page+0x72/0xf0
  Code: c6 48 8b 36 48 83 fe ff 74 53 48 01 d1 48 83 c1 08 48 8b 09 f6
  c1 01 75 7b 66 90 48 89 c1 48 8b 09 f6 c1 01 74 74 5d c3 eb 9e <0f> 0b
  48 ba ff ff ff ff 03 00 00 00 eb ae a9 ff 0f 00 00 75 13 48
  RSP: 0018:ffffa59e73fabb80 EFLAGS: 00010282
  RAX: 00000000ffffffe8 RBX: 0c[PII_REDACTED]0000 RCX: ffffcd[PII_REDACTED]
  RDX: 1ffffffffff7a80a RSI: [PII_REDACTED] RDI: 0c[PII_REDACTED]042b
  RBP: ffffa59e73fabb80 R08: ffff9965ca6e8bb8 R09: [PII_REDACTED]
  R10: ffffffffa5a2f62d R11: 0000030b372e9fff R12: ffff997b79db5738
  R13:[PII_REDACTED]00042b R14: 0c[PII_REDACTED]042b R15: 1ffffffffff7a80a
  FS:  00007f549d1bb700(0000) GS:ffff99d3cf680000(0000) knlGS:[PII_REDACTED]
  CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
  CR2: 0000440d035b3180 CR3: [PII_REDACTED] CR4:[PII_REDACTED]3706e0
  DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
  DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
  Call Trace:
   <TASK>
   change_pte_range+0x36e/0x880
   change_p4d_range+0x2e8/0x670
   change_protection_range+0x14e/0x2c0
   mprotect_fixup+0x1ee/0x330
   do_mprotect_pkey+0x34c/0x440
   __x64_sys_mprotect+0x1d/0x30

It triggers because pfn_swap_entry_to_page() could be called upon e.g. a
genuine swap entry.

Fix it by only calling it when it's a write migration entry where the page*
is used.

[1] https://lore.kernel.org/lkml/CAOUHufaVC2Za-p8m0aiHw6YkheDcrO-C3wRGixwDS32VTS+k1w@mail.gmail.com/
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3d2f78f08cd8388035ac375e731ec1ac1b79b09d; https://git.kernel.org/stable/c/5fcf81e308d1f4ae95f31690d2a80b7061385ff9
CVE: CVE-2022-49993
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

loop: Check for overflow while configuring loop

The userspace can configure a loop using an ioctl call, wherein
a configuration of type loop_config is passed (see lo_ioctl()'s
case on line 1550 of drivers/block/loop.c). This proceeds to call
loop_configure() which in turn calls loop_set_status_from_info()
(see line 1050 of loop.c), passing &config->info which is of type
loop_info64*. This function then sets the appropriate values, like
the offset.

loop_device has lo_offset of type loff_t (see line 52 of loop.c),
which is typdef-chained to long long, whereas loop_info64 has
lo_offset of type __u64 (see line 56 of include/uapi/linux/loop.h).

The function directly copies offset from info to the device as
follows (See line 980 of loop.c):
	lo->lo_offset = info->lo_offset;

This results in an overflow, which triggers a warning in iomap_iter()
due to a call to iomap_iter_done() which has:
	WARN_ON_ONCE(iter->iomap.offset > iter->pos);

Thus, check for negative value during loop_set_status_from_info().

Bug report: https://syzkaller.appspot.com/bug?id=c620fe14aac810396d3c3edc9ad73848bf69a29e
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0455bef69028c65065f16bb04635591b2374249b; https://git.kernel.org/stable/c/18e28817cb516b39de6281f6db9b0618b2cc7b42; https://git.kernel.org/stable/c/[PII_REDACTED]d0dadac071c4d33335a9ea4b8e76cf
CVE: CVE-2022-49994
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

bootmem: remove the vmemmap pages from kmemleak in put_page_bootmem

The vmemmap pages is marked by kmemleak when allocated from memblock. 
Remove it from kmemleak when freeing the page.  Otherwise, when we reuse
the page, kmemleak may report such an error and then stop working.

 kmemleak: Cannot insert 0xffff98fb6eab3d40 into the object search tree (overlaps existing)
 kmemleak: Kernel memory leak detector disabled
 kmemleak: Object 0xffff98fb6be00000 (size 335544320):
 kmemleak:   comm "swapper", pid 0, jiffies[PII_REDACTED]
 kmemleak:   min_count = 0
 kmemleak:   count = 0
 kmemleak:   flags = 0x1
 kmemleak:   checksum = 0
 kmemleak:   backtrace:
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/16a12ee619e39e8112f61b603255c16b73b6264b; https://git.kernel.org/stable/c/9ae15c4ba2be1e5a62503b6d873e84beb5fcbb5a; https://git.kernel.org/stable/c/dd0ff4d12dd284c334f7e9b07f8f335af856ac78
CVE: CVE-2022-49995
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

writeback: avoid use-after-free after removing device

When a disk is removed, bdi_unregister gets called to stop further
writeback and wait for associated delayed work to complete.  However,
wb_inode_writeback_end() may schedule bandwidth estimation dwork after
this has completed, which can result in the timer attempting to access the
just freed bdi_writeback.

Fix this by checking if the bdi_writeback is alive, similar to when
scheduling writeback work.

Since this requires wb->work_lock, and wb_inode_writeback_end() may get
called from interrupt, switch wb->work_lock to an irqsafe lock.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/9a6c710f3bc10bc9cc23e1c080b53245b7f9d5b7; https://git.kernel.org/stable/c/f87904c075515f3e1d8f4a7115869d3b914674fd; https://git.kernel.org/stable/c/f96b9f7c1676923bce871e728bb49c0dfa5013cc
CVE: CVE-2022-49996
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix possible memory leak in btrfs_get_dev_args_from_path()

In btrfs_get_dev_args_from_path(), btrfs_get_bdev_and_sb() can fail if
the path is invalid. In this case, btrfs_get_dev_args_from_path()
returns directly without freeing args->uuid and args->fsid allocated
before, which causes memory leak.

To fix these possible leaks, when btrfs_get_bdev_and_sb() fails,
btrfs_put_dev_args_from_path() is called to clean up the memory.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/4b124ad87244cd7f0883c5eaa38d2326b2154cad; https://git.kernel.org/stable/c/5f52402c77013e4a826394b807dd5ea4dc83bd72; https://git.kernel.org/stable/c/9ea0106a7a3d[PII_REDACTED]e3f17cd52ce99f6707
CVE: CVE-2022-49997
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

net: lantiq_xrx200: restore buffer if memory allocation failed

In a situation where memory allocation fails, an invalid buffer address
is stored. When this descriptor is used again, the system panics in the
build_skb() function when accessing memory.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/3ef2786e32d93e562cd40601248a14ae090de873; https://git.kernel.org/stable/c/c9c3b1775f80fa21f5bff874027d2ccb10f5d90c
CVE: CVE-2022-49998
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

rxrpc: Fix locking in rxrpc's sendmsg

Fix three bugs in the rxrpc's sendmsg implementation:

 (1) rxrpc_new_client_call() should release the socket lock when returning
     an error from rxrpc_get_call_slot().

 (2) rxrpc_wait_for_tx_window_intr() will return without the call mutex
     held in the event that we're interrupted by a signal whilst waiting
     for tx space on the socket or relocking the call mutex afterwards.

     Fix this by: (a) moving the unlock/lock of the call mutex up to
     rxrpc_send_data() such that the lock is not held around all of
     rxrpc_wait_for_tx_window*() and (b) indicating to higher callers
     whether we're return with the lock dropped.  Note that this means
     recvmsg() will not block on this call whilst we're waiting.

 (3) After dropping and regaining the call mutex, rxrpc_send_data() needs
     to go and recheck the state of the tx_pending buffer and the
     tx_total_len check in case we raced with another sendmsg() on the same
     call.

Thinking on this some more, it might make sense to have different locks for
sendmsg() and recvmsg().  There's probably no need to make recvmsg() wait
for sendmsg().  It does mean that recvmsg() can return MSG_EOR indicating
that a call is dead before a sendmsg() to that call returns - but that can
currently happen anyway.

Without fix (2), something like the following can be induced:

	WARNING: bad unlock balance detected!
	5.16.0-rc6-syzkaller #0 Not tainted
	-------------------------------------
	syz-executor011/3597 is trying to release lock (&call->user_mutex) at:
	[<ffffffff885163a3>] rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748
	but there are no more locks to release!

	other info that might help us debug this:
	no locks held by syz-executor011/3597.
	...
	Call Trace:
	 <TASK>
	 __dump_stack lib/dump_stack.c:88 [inline]
	 dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
	 print_unlock_imbalance_bug include/trace/events/lock.h:58 [inline]
	 __lock_release kernel/locking/lockdep.c:5306 [inline]
	 lock_release.cold+0x49/0x4e kernel/locking/lockdep.c:5657
	 __mutex_unlock_slowpath+0x99/0x5e0 kernel/locking/mutex.c:900
	 rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748
	 rxrpc_sendmsg+0x420/0x630 net/rxrpc/af_rxrpc.c:561
	 sock_sendmsg_nosec net/socket.c:704 [inline]
	 sock_sendmsg+0xcf/0x120 net/socket.c:724
	 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409
	 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463
	 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492
	 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
	 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
	 entry_SYSCALL_64_after_hwframe+0x44/0xae

[Thanks to Hawkins Jiawei and Khalid Masum for their attempts to fix this]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/091dc91e119fdd[PII_REDACTED]1724f4e861c6b465; https://git.kernel.org/stable/c/2bc769b8edb158be7379d15f36e23d66cf850053; https://git.kernel.org/stable/c/79e2ca7aa96e80961828ab[PII_REDACTED]b66183cc
CVE: CVE-2022-50001
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nft_tproxy: restrict to prerouting hook

TPROXY is only allowed from prerouting, but nft_tproxy doesn't check this.
This fixes a crash (null dereference) when using tproxy from e.g. output.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0b21edf4cc[PII_REDACTED]e0a4fdf726aa2a62cd9; https://git.kernel.org/stable/c/18bbc3213383a82b05383827f4b1b882e3f0a5a5; https://git.kernel.org/stable/c/343fed6b0daeb528ae5c9d4d84d9ff763ac95619
CVE: CVE-2022-50002
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: LAG, fix logic over MLX5_LAG_FLAG_NDEVS_READY

Only set MLX5_LAG_FLAG_NDEVS_READY if both netdevices are registered.
Doing so guarantees that both ldev->pf[MLX5_LAG_P0].dev and
ldev->pf[MLX5_LAG_P1].dev have valid pointers when
MLX5_LAG_FLAG_NDEVS_READY is set.

The core issue is asymmetry in setting MLX5_LAG_FLAG_NDEVS_READY and
clearing it. Setting it is done wrongly when both
ldev->pf[MLX5_LAG_P0].dev and ldev->pf[MLX5_LAG_P1].dev are set;
clearing it is done right when either of ldev->pf[i].netdev is cleared.

Consider the following scenario:
1. PF0 loads and sets ldev->pf[MLX5_LAG_P0].dev to a valid pointer
2. PF1 loads and sets both ldev->pf[MLX5_LAG_P1].dev and
   ldev->pf[MLX5_LAG_P1].netdev with valid pointers. This results in
   MLX5_LAG_FLAG_NDEVS_READY is set.
3. PF0 is unloaded before setting dev->pf[MLX5_LAG_P0].netdev.
   MLX5_LAG_FLAG_NDEVS_READY remains set.

Further execution of mlx5_do_bond() will result in null pointer
dereference when calling mlx5_lag_is_multipath()

This patch fixes the following call trace actually encountered:

[ 1293.475195] BUG: kernel NULL pointer dereference, address:[PII_REDACTED]0009a8
[ 1293.478756] #PF: supervisor read access in kernel mode
[ 1293.481320] #PF: error_code(0x0000) - not-present page
[ 1293.483686] PGD 0 P4D 0
[ 1293.484434] Oops: 0000 [#1] SMP PTI
[ 1293.485377] CPU: 1 PID: 23690 Comm: kworker/u16:2 Not tainted 5.18.0-rc5_for_upstream_min_debug_2022_05_05_10_13 #1
[ 1293.488039] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
[ 1293.490836] Workqueue: mlx5_lag mlx5_do_bond_work [mlx5_core]
[ 1293.492448] RIP: 0010:mlx5_lag_is_multipath+0x5/0x50 [mlx5_core]
[ 1293.494044] Code: e8 70 40 ff e0 48 8b 14 24 48 83 05 5c 1a 1b 00 01 e9 19 ff ff ff 48 83 05 47 1a 1b 00 01 eb d7 0f 1f 44 00 00 0f 1f 44 00 00 <48> 8b 87 a8 09 00 00 48 85 c0 74 26 48 83 05 a7 1b 1b 00 01 41 b8
[ 1293.498673] RSP: 0018:ffff88811b2fbe40 EFLAGS: 00010202
[ 1293.500152] RAX: ffff88818a94e1c0 RBX: ffff888165eca6c0 RCX: [PII_REDACTED]
[ 1293.501841] RDX: [PII_REDACTED] RSI: ffff88818a94e1c0 RDI: [PII_REDACTED]
[ 1293.503585] RBP: [PII_REDACTED] R08: ffff[PII_REDACTED]40 R09: ffff888165eca73c
[ 1293.505286] R10: [PII_REDACTED] R11: [PII_REDACTED] R12: ffff88818a94e1c0
[ 1293.506979] R13: ffff[PII_REDACTED]00 R14: [PII_REDACTED] R15: ffff[PII_REDACTED]58
[ 1293.508753] FS:  [PII_REDACTED](0000) GS:ffff88852cc40000(0000) knlGS:[PII_REDACTED]
[ 1293.510782] CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
[ 1293.512265] CR2:[PII_REDACTED]0009a8 CR3:[PII_REDACTED]2d4002 CR4:[PII_REDACTED]370ea0
[ 1293.514001] DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
[ 1293.515806] DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/4c040acf5744e87a7b3490f9ec8bedd0d15c9f29; https://git.kernel.org/stable/c/a6e675a66175869b7d87c0e1dd0ddf93e04f8098
CVE: CVE-2022-50005
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

nfc: pn533: Fix use-after-free bugs caused by pn532_cmd_timeout

When the pn532 uart device is detaching, the pn532_uart_remove()
is called. But there are no functions in pn532_uart_remove() that
could delete the cmd_timeout timer, which will cause use-after-free
bugs. The process is shown below:

    (thread 1)                  |        (thread 2)
                                |  pn532_uart_send_frame
pn532_uart_remove               |    mod_timer(&pn532->cmd_timeout,...)
  ...                           |    (wait a time)
  kfree(pn532) //FREE           |    pn532_cmd_timeout
                                |      pn532_uart_send_frame
                                |        pn532->... //USE

This patch adds del_timer_sync() in pn532_uart_remove() in order to
prevent the use-after-free bugs. What's more, the pn53x_unregister_nfc()
is well synchronized, it sets nfc_dev->shutting_down to true and there
are no syscalls could restart the cmd_timeout timer.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/2c71f5d55a86fd5969428abf525c1ae6b1c7b0f5; https://git.kernel.org/stable/c/50403ee6daddf0d7a14e9d3b51a377c39a08ec8c; https://git.kernel.org/stable/c/9c34c33893db7a80d0e4b55c23d3b65e29609cfb
CVE: CVE-2022-50006
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

NFSv4.2 fix problems with __nfs42_ssc_open

A destination server while doing a COPY shouldn't accept using the
passed in filehandle if its not a regular filehandle.

If alloc_file_pseudo() has failed, we need to decrement a reference
on the newly created inode, otherwise it leaks.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/5626f[PII_REDACTED]2ad26fc05445a4d1f818a0992; https://git.kernel.org/stable/c/5e49ea099850feadcbf33c74b4f514a3e8049b91; https://git.kernel.org/stable/c/c2a47f6903e270c308c40ad4a23c17b30a54373c
CVE: CVE-2022-50007
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

xfrm: fix refcount leak in __xfrm_policy_check()

The issue happens on an error path in __xfrm_policy_check(). When the
fetching process of the object `pols[1]` fails, the function simply
returns 0, forgetting to decrement the reference count of `pols[0]`,
which is incremented earlier by either xfrm_sk_policy_lookup() or
xfrm_policy_lookup(). This may result in memory leaks.

Fix it by decreasing the reference count of `pols[0]` in that path.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0769491a8acd3e85ca4c3f65080eac2c824262df; https://git.kernel.org/stable/c/1305d7d4f35ca6f214a2d23b075aa6a924cff3be; https://git.kernel.org/stable/c/18e6b6e2555c93f5ca09f2b85ef1fa025c8accea