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

virtio_net: fix memory leak inside XPD_TX with mergeable

When we call xdp_convert_buff_to_frame() to get xdpf, if it returns
NULL, we should check if xdp_page was allocated by xdp_linearize_page().
If it is newly allocated, it should be freed here alone. Just like any
other "goto err_xdp".
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/18e383afbd7047af7b055df6e25436e0ce28f8a5; https://git.kernel.org/stable/c/7a542bee27c6a57e45c33cbbdc963325fd6493af; https://git.kernel.org/stable/c/d3723eab11196475ef83279571b2b0bd0924cf82
CVE: CVE-2022-50066
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

net: atlantic: fix aq_vec index out of range error

The final update statement of the for loop exceeds the array range, the
dereference of self->aq_vec[i] is not checked and then leads to the
index out of range error.
Also fixed this kind of coding style in other for loop.

[   97.937604] UBSAN: array-index-out-of-bounds in drivers/net/ethernet/aquantia/atlantic/aq_nic.c:1404:48
[   97.937607] index 8 is out of range for type 'aq_vec_s *[8]'
[   97.937608] CPU: 38 PID: 3767 Comm: kworker/u256:18 Not tainted 5.19.0+ #2
[   97.937610] Hardware name: Dell Inc. Precision 7865 Tower/, BIOS 1.0.0 06/12/2022
[   97.937611] Workqueue: events_unbound async_run_entry_fn
[   97.937616] Call Trace:
[   97.937617]  <TASK>
[   97.937619]  dump_stack_lvl+0x49/0x63
[   97.937624]  dump_stack+0x10/0x16
[   97.937626]  ubsan_epilogue+0x9/0x3f
[   97.937627]  __ubsan_handle_out_of_bounds.cold+0x44/0x49
[   97.937629]  ? __scm_send+0x348/0x440
[   97.937632]  ? aq_vec_stop+0x72/0x80 [atlantic]
[   97.937639]  aq_nic_stop+0x1b6/0x1c0 [atlantic]
[   97.937644]  aq_suspend_common+0x88/0x90 [atlantic]
[   97.937648]  aq_pm_suspend_poweroff+0xe/0x20 [atlantic]
[   97.937653]  pci_pm_suspend+0x7e/0x1a0
[   97.937655]  ? pci_pm_suspend_noirq+0x2b0/0x2b0
[   97.937657]  dpm_run_callback+0x54/0x190
[   97.937660]  __device_suspend+0x14c/0x4d0
[   97.937661]  async_suspend+0x23/0x70
[   97.937663]  async_run_entry_fn+0x33/0x120
[   97.937664]  process_one_work+0x21f/0x3f0
[   97.937666]  worker_thread+0x4a/0x3c0
[   97.937668]  ? process_one_work+0x3f0/0x3f0
[   97.937669]  kthread+0xf0/0x120
[   97.937671]  ? kthread_complete_and_exit+0x20/0x20
[   97.937672]  ret_from_fork+0x22/0x30
[   97.937676]  </TASK>

v2. fixed "warning: variable 'aq_vec' set but not used"

v3. simplified a for loop
CVSS Score: 7.8 (HIGH)
CWE: CWE-129
References: https://git.kernel.org/stable/c/23bf[PII_REDACTED]4ab5c8cc9bb460fd1209b39b5; https://git.kernel.org/stable/c/2ba5e47fb75fbb8fab45f5c1bc8d5c33d8834bd3; https://git.kernel.org/stable/c/422a02a771599cac96f2b2900d993e0bb7ba5b88
CVE: CVE-2022-50067
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: unset reloc control if transaction commit fails in prepare_to_relocate()

In btrfs_relocate_block_group(), the rc is allocated.  Then
btrfs_relocate_block_group() calls

relocate_block_group()
  prepare_to_relocate()
    set_reloc_control()

that assigns rc to the variable fs_info->reloc_ctl. When
prepare_to_relocate() returns, it calls

btrfs_commit_transaction()
  btrfs_start_dirty_block_groups()
    btrfs_alloc_path()
      kmem_cache_zalloc()

which may fail for example (or other errors could happen). When the
failure occurs, btrfs_relocate_block_group() detects the error and frees
rc and doesn't set fs_info->reloc_ctl to NULL. After that, in
btrfs_init_reloc_root(), rc is retrieved from fs_info->reloc_ctl and
then used, which may cause a use-after-free bug.

This possible bug can be triggered by calling btrfs_ioctl_balance()
before calling btrfs_ioctl_defrag().

To fix this possible bug, in prepare_to_relocate(), check if
btrfs_commit_transaction() fails. If the failure occurs,
unset_reloc_control() is called to set fs_info->reloc_ctl to NULL.

The error log in our fault-injection testing is shown as follows:

  [   58.751070] BUG: KASAN: use-after-free in btrfs_init_reloc_root+0x7ca/0x920 [btrfs]
  ...
  [   58.753577] Call Trace:
  ...
  [   58.755800]  kasan_report+0x45/0x60
  [   58.756066]  btrfs_init_reloc_root+0x7ca/0x920 [btrfs]
  [   58.757304]  record_root_in_trans+0x792/0xa10 [btrfs]
  [   58.757748]  btrfs_record_root_in_trans+0x463/0x4f0 [btrfs]
  [   58.758231]  start_transaction+0x896/0x2950 [btrfs]
  [   58.758661]  btrfs_defrag_root+0x250/0xc00 [btrfs]
  [   58.759083]  btrfs_ioctl_defrag+0x467/0xa00 [btrfs]
  [   58.759513]  btrfs_ioctl+0x3c95/0x114e0 [btrfs]
  ...
  [   58.768510] Allocated by task 23683:
  [   58.768777]  ____kasan_kmalloc+0xb5/0xf0
  [   58.769069]  __kmalloc+0x227/0x3d0
  [   58.769325]  alloc_reloc_control+0x10a/0x3d0 [btrfs]
  [   58.769755]  btrfs_relocate_block_group+0x7aa/0x1e20 [btrfs]
  [   58.770228]  btrfs_relocate_chunk+0xf1/0x760 [btrfs]
  [   58.770655]  __btrfs_balance+0x1326/0x1f10 [btrfs]
  [   58.771071]  btrfs_balance+0x3150/0x3d30 [btrfs]
  [   58.771472]  btrfs_ioctl_balance+0xd84/0x1410 [btrfs]
  [   58.771902]  btrfs_ioctl+0x4caa/0x114e0 [btrfs]
  ...
  [   58.773337] Freed by task 23683:
  ...
  [   58.774815]  kfree+0xda/0x2b0
  [   58.775038]  free_reloc_control+0x1d6/0x220 [btrfs]
  [   58.775465]  btrfs_relocate_block_group+0x115c/0x1e20 [btrfs]
  [   58.775944]  btrfs_relocate_chunk+0xf1/0x760 [btrfs]
  [   58.776369]  __btrfs_balance+0x1326/0x1f10 [btrfs]
  [   58.776784]  btrfs_balance+0x3150/0x3d30 [btrfs]
  [   58.777185]  btrfs_ioctl_balance+0xd84/0x1410 [btrfs]
  [   58.777621]  btrfs_ioctl+0x4caa/0x114e0 [btrfs]
  ...
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/5d741afed0bac206640cc64d77b97853283cf719; https://git.kernel.org/stable/c/78f8c2370e3d33e35f23bdc648653d779aeacb6e; https://git.kernel.org/stable/c/85f02d6c856b9f3a0acf5219de6e32f58b9778eb
CVE: CVE-2022-50070
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

mptcp: do not queue data on closed subflows

Dipanjan reported a syzbot splat at close time:

WARNING: CPU: 1 PID: 10818 at net/ipv4/af_inet.c:153
inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153
Modules linked in: uio_ivshmem(OE) uio(E)
CPU: 1 PID: 10818 Comm: kworker/1:16 Tainted: G           OE
5.19.0-rc6-g2eae0556bb9d #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153
Code: 21 02 00 00 41 8b 9c 24 28 02 00 00 e9 07 ff ff ff e8 34 4d 91
f9 89 ee 4c 89 e7 e8 4a 47 60 ff e9 a6 fc ff ff e8 20 4d 91 f9 <0f> 0b
e9 84 fe ff ff e8 14 4d 91 f9 0f 0b e9 d4 fd ff ff e8 08 4d
RSP: 0018:ffffc9001b35fa78 EFLAGS: 00010246
RAX: [PII_REDACTED] RBX:[PII_REDACTED]2879d0 RCX: ffff8881326f3b00
RDX: [PII_REDACTED] RSI: ffff8881326f3b00 RDI: [PII_REDACTED]
RBP: ffff[PII_REDACTED]74 R08: ffffffff87e983a0 R09: [PII_REDACTED]
R10: [PII_REDACTED] R11:[PII_REDACTED]0004ea R12: ffff[PII_REDACTED]00
R13: ffff[PII_REDACTED]28 R14: [PII_REDACTED] R15: ffff88817e38e258
FS:  [PII_REDACTED](0000) GS:ffff8881f5f00000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2:[PII_REDACTED]007bc0 CR3: [PII_REDACTED] CR4:[PII_REDACTED]150ee0
Call Trace:
 <TASK>
 __sk_destruct+0x4f/0x8e0 net/core/sock.c:2067
 sk_destruct+0xbd/0xe0 net/core/sock.c:2112
 __sk_free+0xef/0x3d0 net/core/sock.c:2123
 sk_free+0x78/0xa0 net/core/sock.c:2134
 sock_put include/net/sock.h:1927 [inline]
 __mptcp_close_ssk+0x50f/0x780 net/mptcp/protocol.c:2351
 __mptcp_destroy_sock+0x332/0x760 net/mptcp/protocol.c:2828
 mptcp_worker+0x5d2/0xc90 net/mptcp/protocol.c:2586
 process_one_work+0x9cc/0x1650 kernel/workqueue.c:2289
 worker_thread+0x623/0x1070 kernel/workqueue.c:2436
 kthread+0x2e9/0x3a0 kernel/kthread.c:376
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302
 </TASK>

The root cause of the problem is that an mptcp-level (re)transmit can
race with mptcp_close() and the packet scheduler checks the subflow
state before acquiring the socket lock: we can try to (re)transmit on
an already closed ssk.

Fix the issue checking again the subflow socket status under the
subflow socket lock protection. Additionally add the missing check
for the fallback-to-tcp case.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/8caf5c15b5288d52d9c89374d6c10fa32ee84ec5; https://git.kernel.org/stable/c/c886d70286bf3ad411eb3d689328a67f7102c6ae; https://git.kernel.org/stable/c/fb9c73ef2ac2ec816efdc8b9267bc04e1369c20b
CVE: CVE-2022-50071
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

mptcp: move subflow cleanup in mptcp_destroy_common()

If the mptcp socket creation fails due to a CGROUP_INET_SOCK_CREATE
eBPF program, the MPTCP protocol ends-up leaking all the subflows:
the related cleanup happens in __mptcp_destroy_sock() that is not
invoked in such code path.

Address the issue moving the subflow sockets cleanup in the
mptcp_destroy_common() helper, which is invoked in every msk cleanup
path.

Additionally get rid of the intermediate list_splice_init step, which
is an unneeded relic from the past.

The issue is present since before the reported root cause commit, but
any attempt to backport the fix before that hash will require a complete
rewrite.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/6139039c8fc5c9dbcdc3ad389b9a6d0cacb4d693; https://git.kernel.org/stable/c/c0bf3c6aa444a5ef44acc57ef6cfa53fd4fc1c9b
CVE: CVE-2022-50072
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

NFSv4/pnfs: Fix a use-after-free bug in open

If someone cancels the open RPC call, then we must not try to free
either the open slot or the layoutget operation arguments, since they
are likely still in use by the hung RPC call.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0fffb46ff3d5ed4668aca96441ec7a25b793bd6f; https://git.kernel.org/stable/c/2135e5d56278ffdb1c2e6d325dc6b87f669b9dac; https://git.kernel.org/stable/c/76ffd[PII_REDACTED]298f34b76102b40dea89de616
CVE: CVE-2022-50073
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

net: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is null

Fixes a NULL pointer derefence bug triggered from tap driver.
When tap_get_user calls virtio_net_hdr_to_skb the skb->dev is null
(in tap.c skb->dev is set after the call to virtio_net_hdr_to_skb)
virtio_net_hdr_to_skb calls dev_parse_header_protocol which
needs skb->dev field to be valid.

The line that trigers the bug is in dev_parse_header_protocol
(dev is at offset 0x10 from skb and is stored in RAX register)
  if (!dev->header_ops || !dev->header_ops->parse_protocol)
  22e1:   mov    0x10(%rbx),%rax
  22e5:	  mov    0x230(%rax),%rax

Setting skb->dev before the call in tap.c fixes the issue.

BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
RIP: 0010:virtio_net_hdr_to_skb.constprop.0+0x335/0x410 [tap]
Code: c0 0f 85 b7 fd ff ff eb d4 41 39 c6 77 cf 29 c6 48 89 df 44 01 f6 e8 7a 79 83 c1 48 85 c0 0f 85 d9 fd ff ff eb b7 48 8b 43 10 <48> 8b 80 30 02 00 00 48 85 c0 74 55 48 8b 40 28 48 85 c0 74 4c 48
RSP: 0018:ffffc90005c27c38 EFLAGS: 00010246
RAX: [PII_REDACTED] RBX: ffff888298f25300 RCX: [PII_REDACTED]
RDX: [PII_REDACTED] RSI: ffffc90005c27cb6 RDI: ffff888298f25300
RBP: ffffc90005c27c80 R08: 00000000ffffffea R09:[PII_REDACTED]0007e8
R10: ffff88858ec77458 R11: [PII_REDACTED] R12: [PII_REDACTED]
R13: [PII_REDACTED] R14: ffffc90005c27e08 R15: ffffc90005c27cb6
FS:  [PII_REDACTED](0000) GS:ffff88858ec40000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: [PII_REDACTED] CR3: [PII_REDACTED] CR4:[PII_REDACTED]3706e0
Call Trace:
 tap_get_user+0x3f1/0x540 [tap]
 tap_sendmsg+0x56/0x362 [tap]
 ? get_tx_bufs+0xc2/0x1e0 [vhost_net]
 handle_tx_copy+0x114/0x670 [vhost_net]
 handle_tx+0xb0/0xe0 [vhost_net]
 handle_tx_kick+0x15/0x20 [vhost_net]
 vhost_worker+0x7b/0xc0 [vhost]
 ? vhost_vring_call_reset+0x40/0x40 [vhost]
 kthread+0xfa/0x120
 ? kthread_complete_and_exit+0x20/0x20
 ret_from_fork+0x1f/0x30
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/4f61f133f354853bc394ec7d6028adb9b02dd701; https://git.kernel.org/stable/c/dd29648fcf69339713f2d25f7014ae905dcdfc18
CVE: CVE-2022-50074
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

apparmor: Fix memleak in aa_simple_write_to_buffer()

When copy_from_user failed, the memory is freed by kvfree. however the
management struct and data blob are allocated independently, so only
kvfree(data) cause a memleak issue here. Use aa_put_loaddata(data) to
fix this issue.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/417ea9fe972d2654a268ad66e89c8fcae67017c3; https://git.kernel.org/stable/c/6500eb3a48ac221051b1791818a1ac74744ef617; https://git.kernel.org/stable/c/6583edbf459de2e06b9759f264c0ae27e452b97a
CVE: CVE-2022-50075
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

tracing/eprobes: Have event probes be consistent with kprobes and uprobes

Currently, if a symbol "@" is attempted to be used with an event probe
(eprobes), it will cause a NULL pointer dereference crash.

Both kprobes and uprobes can reference data other than the main registers.
Such as immediate address, symbols and the current task name. Have eprobes
do the same thing.

For "comm", if "comm" is used and the event being attached to does not
have the "comm" field, then make it the "$comm" that kprobes has. This is
consistent to the way histograms and filters work.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/47cc883f21fa3bcf24891b4b455f4cd461ce2d6e; https://git.kernel.org/stable/c/6a832ec3d680b3a4f4fad[PII_REDACTED]d71bae501; https://git.kernel.org/stable/c/b489aca082a23033a3d8355cfb0032f0e2523440
CVE: CVE-2022-50076
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

cifs: Fix memory leak on the deferred close

xfstests on smb21 report kmemleak as below:

  unreferenced object 0xffff8881767d6200 (size 64):
    comm "xfs_io", pid 1284, jiffies[PII_REDACTED] (age 20.789s)
    hex dump (first 32 bytes):
      80 5a d0 11 81 88 ff ff 78 8a aa 63 81 88 ff ff  .Z......x..c....
      00 71 99 76 81 88 ff ff 00 00 00 00 00 00 00 00  .q.v............
    backtrace:
      [<00000000ad04e6ea>] cifs_close+0x92/0x2c0
      [<[PII_REDACTED]b93c82>] __fput+0xff/0x3f0
      [<00000000d8116851>] task_work_run+0x85/0xc0
      [<[PII_REDACTED]e14f9e>] do_exit+0x5e5/0x1240
      [<00000000fb492b95>] do_group_exit+0x58/0xe0
      [<[PII_REDACTED]9a32d9>] __x64_sys_exit_group+0x28/0x30
      [<00000000e3f7d8e9>] do_syscall_64+0x35/0x80
      [<[PII_REDACTED]2e8a0b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0

When cancel the deferred close work, we should also cleanup the struct
cifs_deferred_close.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/60b6d38add7b9c17d6e5d49ee8e930ea1a5650c5; https://git.kernel.org/stable/c/860efae127888ae535bc4eda1b7f27642727c69e; https://git.kernel.org/stable/c/ca08d0eac020d48a3141dbec0a3cf64fbdb17cde
CVE: CVE-2022-50077
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

apparmor: fix reference count leak in aa_pivotroot()

The aa_pivotroot() function has a reference counting bug in a specific
path. When aa_replace_current_label() returns on success, the function
forgets to decrement the reference count of “target”, which is
increased earlier by build_pivotroot(), causing a reference leak.

Fix it by decreasing the refcount of “target” in that path.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/11c3627ec6b56c1525013f336f41b79a983b4d46; https://git.kernel.org/stable/c/2ceeb3296e9dde1d[PII_REDACTED]affcefdea605e2; https://git.kernel.org/stable/c/3ca40ad7afae144169a43988ef1a3f16182faf0a
CVE: CVE-2022-50078
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

tracing/eprobes: Do not allow eprobes to use $stack, or % for regs

While playing with event probes (eprobes), I tried to see what would
happen if I attempted to retrieve the instruction pointer (%rip) knowing
that event probes do not use pt_regs. The result was:

 BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: 0000 [#1] PREEMPT SMP PTI
 CPU: 1 PID: 1847 Comm: trace-cmd Not tainted 5.19.0-rc5-test+ #309
 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01
v03.03 07/14/2016
 RIP: 0010:get_event_field.isra.0+0x0/0x50
 Code: ff 48 c7 c7 c0 8f 74 a1 e8 3d 8b f5 ff e8 88 09 f6 ff 4c 89 e7 e8
50 6a 13 00 48 89 ef 5b 5d 41 5c 41 5d e9 42 6a 13 00 66 90 <48> 63 47 24
8b 57 2c 48 01 c6 8b 47 28 83 f8 02 74 0e 83 f8 04 74
 RSP: 0018:ffff916c394bbaf0 EFLAGS: 00010086
 RAX: ffff916c854041d8 RBX: ffff916c8d9fbf50 RCX: ffff916c255d2000
 RDX: [PII_REDACTED] RSI: ffff916c255d2008 RDI: [PII_REDACTED]
 RBP: [PII_REDACTED] R08: ffff916c3a2a0c08 R09: ffff916c394bbda8
 R10: [PII_REDACTED] R11: [PII_REDACTED] R12: ffff916c854041d8
 R13: ffff916c854041b0 R14: [PII_REDACTED] R15: [PII_REDACTED]
 FS:  [PII_REDACTED](0000) GS:ffff916c9ea40000(0000)
knlGS:[PII_REDACTED]
 CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
 CR2: [PII_REDACTED] CR3: 000000011b60a002 CR4:[PII_REDACTED]1706e0
 Call Trace:
  <TASK>
  get_eprobe_size+0xb4/0x640
  ? __mod_node_page_state+0x72/0xc0
  __eprobe_trace_func+0x59/0x1a0
  ? __mod_lruvec_page_state+0xaa/0x1b0
  ? page_remove_file_rmap+0x14/0x230
  ? page_remove_rmap+0xda/0x170
  event_triggers_call+0x52/0xe0
  trace_event_buffer_commit+0x18f/0x240
  trace_event_raw_event_sched_wakeup_template+0x7a/0xb0
  try_to_wake_up+0x260/0x4c0
  __wake_up_common+0x80/0x180
  __wake_up_common_lock+0x7c/0xc0
  do_notify_parent+0x1c9/0x2a0
  exit_notify+0x1a9/0x220
  do_exit+0x2ba/0x450
  do_group_exit+0x2d/0x90
  __x64_sys_exit_group+0x14/0x20
  do_syscall_64+0x3b/0x90
  entry_SYSCALL_64_after_hwframe+0x46/0xb0

Obviously this is not the desired result.

Move the testing for TPARG_FL_TPOINT which is only used for event probes
to the top of the "$" variable check, as all the other variables are not
used for event probes. Also add a check in the register parsing "%" to
fail if an event probe is used.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2673c60ee67e71f2ebe34386e62d348f71edee47; https://git.kernel.org/stable/c/7c262114a576d94c0ced80e232bbb17391a55908; https://git.kernel.org/stable/c/ba53c21ce9773743b8e0a8ada048c96ff2d55c67
CVE: CVE-2022-50079
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check correct bounds for stream encoder instances for DCN303

[Why & How]
eng_id for DCN303 cannot be more than 1, since we have only two
instances of stream encoders.

Check the correct boundary condition for engine ID for DCN303 prevent
the potential out of bounds access.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/4c31dca1799612eb3b6413e3e574f90c3fb8f865; https://git.kernel.org/stable/c/82a27c1855445d48aacc67b0c0640f3dadebe52f; https://git.kernel.org/stable/c/89b008222c2bf21e50219725caed31590edfd9d1
CVE: CVE-2022-50080
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

tee: add overflow check in register_shm_helper()

With special lengths supplied by user space, register_shm_helper() has
an integer overflow when calculating the number of pages covered by a
supplied user space memory region.

This causes internal_get_user_pages_fast() a helper function of
pin_user_pages_fast() to do a NULL pointer dereference:

  Unable to handle kernel NULL pointer dereference at virtual address [PII_REDACTED]
  Modules linked in:
  CPU: 1 PID: 173 Comm: optee_example_a Not tainted 5.19.0 #11
  Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
  pc : internal_get_user_pages_fast+0x474/0xa80
  Call trace:
   internal_get_user_pages_fast+0x474/0xa80
   pin_user_pages_fast+0x24/0x4c
   register_shm_helper+0x194/0x330
   tee_shm_register_user_buf+0x78/0x120
   tee_ioctl+0xd0/0x11a0
   __arm64_sys_ioctl+0xa8/0xec
   invoke_syscall+0x48/0x114

Fix this by adding an an explicit call to access_ok() in
tee_shm_register_user_buf() to catch an invalid user space address
early.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2f8e79a1a6128214cb9b205a9869341af5dfb16b; https://git.kernel.org/stable/c/573ae4f13f630d6660008f1974c0a8a29c30e18a; https://git.kernel.org/stable/c/578c349570d2a[PII_REDACTED]83b36e0ec7a25c053
CVE: CVE-2022-50081
Published: 2025-06-18
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2022-50082
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: fix warning in ext4_iomap_begin as race between bmap and write

We got issue as follows:
------------[ cut here ]------------
WARNING: CPU: 3 PID: 9310 at fs/ext4/inode.c:3441 ext4_iomap_begin+0x182/0x5d0
RIP: 0010:ext4_iomap_begin+0x182/0x5d0
RSP: 0018:ffff88812460fa08 EFLAGS: 00010293
RAX: ffff88811f168000 RBX: [PII_REDACTED] RCX: ffffffff97793c12
RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: [PII_REDACTED]
RBP: ffff88812c669160 R08: ffff88811f168000 R09: ffffed10258cd20f
R10: ffff88812c669077 R11: ffffed10258cd20e R12: [PII_REDACTED]
R13:[PII_REDACTED]0000a4 R14:[PII_REDACTED]00000c R15: ffff88812c6691ee
FS:  00007fd0d6ff3740(0000) GS:ffff8883af180000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 00007fd0d6dda290 CR3:[PII_REDACTED]a62000 CR4:[PII_REDACTED]0006e0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
Call Trace:
 iomap_apply+0x119/0x570
 iomap_bmap+0x124/0x150
 ext4_bmap+0x14f/0x250
 bmap+0x55/0x80
 do_vfs_ioctl+0x952/0xbd0
 __x64_sys_ioctl+0xc6/0x170
 do_syscall_64+0x33/0x40
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

Above issue may happen as follows:
          bmap                    write
bmap
  ext4_bmap
    iomap_bmap
      ext4_iomap_begin
                            ext4_file_write_iter
			      ext4_buffered_write_iter
			        generic_perform_write
				  ext4_da_write_begin
				    ext4_da_write_inline_data_begin
				      ext4_prepare_inline_data
				        ext4_create_inline_data
					  ext4_set_inode_flag(inode,
						EXT4_INODE_INLINE_DATA);
      if (WARN_ON_ONCE(ext4_has_inline_data(inode))) ->trigger bug_on

To solved above issue hold inode lock in ext4_bamp.
CVSS Score: 7.0 (HIGH)
CWE: CWE-362
References: https://git.kernel.org/stable/c/30dfb75e1f8645404a536c74d468d498adcd4e74; https://git.kernel.org/stable/c/51ae846cff568c8c29921b1b28eb2dfbcd4ac12d; https://git.kernel.org/stable/c/a9fe6d1e3d343d7309f501b1f48020ce7127221f
CVE: CVE-2022-50083
Published: 2025-06-18
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.