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

wifi: wil6210: debugfs: fix uninitialized variable use in `wil_write_file_wmi()`

Commit 7a4836560a61 changes simple_write_to_buffer() with memdup_user()
but it forgets to change the value to be returned that came from
simple_write_to_buffer() call. It results in the following warning:

  warning: variable 'rc' is uninitialized when used here [-Wuninitialized]
           return rc;
                  ^~

Remove rc variable and just return the passed in length if the
memdup_user() succeeds.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/409bd72e544fdf4809ea0dac337bb5a1f11a25a9; https://git.kernel.org/stable/c/52b11a48cf073e0aab923ae809a765d756cecf13; https://git.kernel.org/stable/c/689e5caf63e99e15d2f485ec297c1bf9243e0e28
CVE: CVE-2022-50166
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: When HCI work queue is drained, only queue chained work

The HCI command, event, and data packet processing workqueue is drained
to avoid deadlock in commit
76727c02c1e1 ("Bluetooth: Call drain_workqueue() before resetting state").

There is another delayed work, which will queue command to this drained
workqueue. Which results in the following error report:

Bluetooth: hci2: command 0x040f tx timeout
WARNING: CPU: 1 PID: 18374 at kernel/workqueue.c:1438 __queue_work+0xdad/0x1140
Workqueue: events hci_cmd_timeout
RIP: 0010:__queue_work+0xdad/0x1140
RSP: 0000:ffffc90002cffc60 EFLAGS: 00010093
RAX: [PII_REDACTED] RBX: ffff8880b9d3ec00 RCX: [PII_REDACTED]
RDX: ffff888024ba0000 RSI: ffffffff814e048d RDI: ffff8880b9d3ec08
RBP: [PII_REDACTED] R08: [PII_REDACTED] R09: 00000000b9d39700
R10: ffffffff814f73c6 R11: [PII_REDACTED] R12: ffff88807cce4c60
R13: [PII_REDACTED] R14: ffff8880796d8800 R15: ffff8880796d8800
FS:  [PII_REDACTED](0000) GS:ffff8880b9d00000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 000000c0174b4000 CR3: 000000007cae9000 CR4:[PII_REDACTED]3506e0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
Call Trace:
 <TASK>
 ? queue_work_on+0xcb/0x110
 ? lockdep_hardirqs_off+0x90/0xd0
 queue_work_on+0xee/0x110
 process_one_work+0x996/0x1610
 ? pwq_dec_nr_in_flight+0x2a0/0x2a0
 ? rwlock_bug.part.0+0x90/0x90
 ? _raw_spin_lock_irq+0x41/0x50
 worker_thread+0x665/0x1080
 ? process_one_work+0x1610/0x1610
 kthread+0x2e9/0x3a0
 ? kthread_complete_and_exit+0x40/0x40
 ret_from_fork+0x1f/0x30
 </TASK>

To fix this, we can add a new HCI_DRAIN_WQ flag, and don't queue the
timeout workqueue while command workqueue is draining.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/3b[PII_REDACTED]58f5c0587862b6dc03e96a252bba; https://git.kernel.org/stable/c/4bf367fa1fefabdf14938d0ac9ed[PII_REDACTED]2e; https://git.kernel.org/stable/c/877afadad2dce8aae1f2aad8ce47e072d4f6165e
CVE: CVE-2022-50167
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: fix potential 32-bit overflow when accessing ARRAY map element

If BPF array map is bigger than 4GB, element pointer calculation can
overflow because both index and elem_size are u32. Fix this everywhere
by forcing 64-bit multiplication. Extract this formula into separate
small helper and use it consistently in various places.

Speculative-preventing formula utilizing index_mask trick is left as is,
but explicit u64 casts are added in both places.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190
References: https://git.kernel.org/stable/c/063e092534d4c6785228e5b1eb6e9329f66ccbe4; https://git.kernel.org/stable/c/3c7256b880b3a5aa1895fd169a34aa4224a11862; https://git.kernel.org/stable/c/87ac0d[PII_REDACTED]44e24382a87aa19acc4cd3d4
CVE: CVE-2022-50168
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf, x86: fix freeing of not-finalized bpf_prog_pack

syzbot reported a few issues with bpf_prog_pack [1], [2]. This only happens
with multiple subprogs. In jit_subprogs(), we first call bpf_int_jit_compile()
on each sub program. And then, we call it on each sub program again. jit_data
is not freed in the first call of bpf_int_jit_compile(). Similarly we don't
call bpf_jit_binary_pack_finalize() in the first call of bpf_int_jit_compile().

If bpf_int_jit_compile() failed for one sub program, we will call
bpf_jit_binary_pack_finalize() for this sub program. However, we don't have a
chance to call it for other sub programs. Then we will hit "goto out_free" in
jit_subprogs(), and call bpf_jit_free on some subprograms that haven't got
bpf_jit_binary_pack_finalize() yet.

At this point, bpf_jit_binary_pack_free() is called and the whole 2MB page is
freed erroneously.

Fix this with a custom bpf_jit_free() for x86_64, which calls
bpf_jit_binary_pack_finalize() if necessary. Also, with custom
bpf_jit_free(), bpf_prog_aux->use_bpf_prog_pack is not needed any more,
remove it.

[1] https://syzkaller.appspot.com/bug?extid=2f649ec6d2eea1495a8f
[2] https://syzkaller.appspot.com/bug?extid=87f65c75f4a72db05445
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/1d5f82d9dd477d5c66e0214a68c3e4f308eadd6d; https://git.kernel.org/stable/c/60e66074812dde9cde3d99cdd3caa9e40f1a4516; https://git.kernel.org/stable/c/f91ce608a79c0db3e72bd63c23e011a9ebc31505
CVE: CVE-2022-50169
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: wil6210: debugfs: fix info leak in wil_write_file_wmi()

The simple_write_to_buffer() function will succeed if even a single
byte is initialized.  However, we need to initialize the whole buffer
to prevent information leaks.  Just use memdup_user().
CVSS Score: 7.1 (HIGH)
CWE: CWE-909
References: https://git.kernel.org/stable/c/05ceda14ef7c73104e709c414c3680d8a59f51d4; https://git.kernel.org/stable/c/074e865b37da55aa87baa16d68b96896f85f8adb; https://git.kernel.org/stable/c/4615458db7793fadc6d546ac3564b36819e77a22
CVE: CVE-2022-50170
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

kunit: executor: Fix a memory leak on failure in kunit_filter_tests

It's possible that memory allocation for 'filtered' will fail, but for the
copy of the suite to succeed. In this case, the copy could be leaked.

Properly free 'copy' in the error case for the allocation of 'filtered'
failing.

Note that there may also have been a similar issue in
kunit_filter_subsuites, before it was removed in "kunit: flatten
kunit_suite*** to kunit_suite** in .kunit_test_suites".

This was reported by clang-analyzer via the kernel test robot, here:
https://lore.kernel.org/all/c8073b8e-7b9e-0830-4177-87c12f16349c@intel.com/

And by smatch via Dan Carpenter and the kernel test robot:
https://lore.kernel.org/all/[PII_REDACTED]28.ASjx88yj-lkp@intel.com/
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/7d69764fa3442c7615a75c6b5c02eaa1f274bccf; https://git.kernel.org/stable/c/94681e289bf5d10c9db9db143d1a22d8717205c5; https://git.kernel.org/stable/c/a8a7e3ced362b88b659ab[PII_REDACTED]6ff975982
CVE: CVE-2022-50171
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: hisilicon/sec - don't sleep when in softirq

When kunpeng920 encryption driver is used to deencrypt and decrypt
packets during the softirq, it is not allowed to use mutex lock. The
kernel will report the following error:

BUG: scheduling while atomic: swapper/57/0/0x00000300
Call trace:
dump_backtrace+0x0/0x1e4
show_stack+0x20/0x2c
dump_stack+0xd8/0x140
__schedule_bug+0x68/0x80
__schedule+0x728/0x840
schedule+0x50/0xe0
schedule_preempt_disabled+0x18/0x24
__mutex_lock.constprop.0+0x594/0x5dc
__mutex_lock_slowpath+0x1c/0x30
mutex_lock+0x50/0x60
sec_request_init+0x8c/0x1a0 [hisi_sec2]
sec_process+0x28/0x1ac [hisi_sec2]
sec_skcipher_crypto+0xf4/0x1d4 [hisi_sec2]
sec_skcipher_encrypt+0x1c/0x30 [hisi_sec2]
crypto_skcipher_encrypt+0x2c/0x40
crypto_authenc_encrypt+0xc8/0xfc [authenc]
crypto_aead_encrypt+0x2c/0x40
echainiv_encrypt+0x144/0x1a0 [echainiv]
crypto_aead_encrypt+0x2c/0x40
esp_output_tail+0x348/0x5c0 [esp4]
esp_output+0x120/0x19c [esp4]
xfrm_output_one+0x25c/0x4d4
xfrm_output_resume+0x6c/0x1fc
xfrm_output+0xac/0x3c0
xfrm4_output+0x64/0x130
ip_build_and_send_pkt+0x158/0x20c
tcp_v4_send_synack+0xdc/0x1f0
tcp_conn_request+0x7d0/0x994
tcp_v4_conn_request+0x58/0x6c
tcp_v6_conn_request+0xf0/0x100
tcp_rcv_state_process+0x1cc/0xd60
tcp_v4_do_rcv+0x10c/0x250
tcp_v4_rcv+0xfc4/0x10a4
ip_protocol_deliver_rcu+0xf4/0x200
ip_local_deliver_finish+0x58/0x70
ip_local_deliver+0x68/0x120
ip_sublist_rcv_finish+0x70/0x94
ip_list_rcv_finish.constprop.0+0x17c/0x1d0
ip_sublist_rcv+0x40/0xb0
ip_list_rcv+0x140/0x1dc
__netif_receive_skb_list_core+0x154/0x28c
__netif_receive_skb_list+0x120/0x1a0
netif_receive_skb_list_internal+0xe4/0x1f0
napi_complete_done+0x70/0x1f0
gro_cell_poll+0x9c/0xb0
napi_poll+0xcc/0x264
net_rx_action+0xd4/0x21c
__do_softirq+0x130/0x358
irq_exit+0x11c/0x13c
__handle_domain_irq+0x88/0xf0
gic_handle_irq+0x78/0x2c0
el1_irq+0xb8/0x140
arch_cpu_idle+0x18/0x40
default_idle_call+0x5c/0x1c0
cpuidle_idle_call+0x174/0x1b0
do_idle+0xc8/0x160
cpu_startup_entry+0x30/0x11c
secondary_start_kernel+0x158/0x1e4
softirq: huh, entered softirq 3 NET_RX[PII_REDACTED]774ee4 with
preempt_count 00000100, exited with fffffe00?
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/02884a4f12de11f54d4ca67a07dd1f111d96fdbd; https://git.kernel.org/stable/c/16e18a8ac7c9748cf35a8d2f0ba2c6e8850e7568; https://git.kernel.org/stable/c/4a461ba5b9753352f438824fdd915cba675b1733
CVE: CVE-2022-50172
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

mt76: mt76x02u: fix possible memory leak in __mt76x02u_mcu_send_msg

Free the skb if mt76u_bulk_msg fails in __mt76x02u_mcu_send_msg routine.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/2f53ba46d8c97aca681adbe5098e1f84580c446d; https://git.kernel.org/stable/c/3ad958bc488e3ecb0207d31621c00efb86f17482; https://git.kernel.org/stable/c/cffd93411575afd987788e2ec3cb8eaff70f0215
CVE: CVE-2022-50173
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/msm/mdp5: Fix global state lock backoff

We need to grab the lock after the early return for !hwpipe case.
Otherwise, we could have hit contention yet still returned 0.

Fixes an issue that the new CONFIG_DRM_DEBUG_MODESET_LOCK stuff flagged
in CI:

   WARNING: CPU: 0 PID: 282 at drivers/gpu/drm/drm_modeset_lock.c:296 drm_modeset_lock+0xf8/0x154
   Modules linked in:
   CPU: 0 PID: 282 Comm: kms_cursor_lega Tainted: G        W         5.19.0-rc2-15930-g875cc8bc536a #1
   Hardware name: Qualcomm Technologies, Inc. DB820c (DT)
   pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
   pc : drm_modeset_lock+0xf8/0x154
   lr : drm_atomic_get_private_obj_state+0x84/0x170
   sp : ffff80000cfab6a0
   x29: ffff80000cfab6a0 x28: [PII_REDACTED] x27: ffff000083bc4d00
   x26: [PII_REDACTED] x25: [PII_REDACTED] x24: ffff80000957ca58
   x23: [PII_REDACTED] x22: ffff000081ace080 x21: [PII_REDACTED]
   x20: ffff000081acec18 x19: ffff80000cfabb80 x18: [PII_REDACTED]
   x17: [PII_REDACTED] x16: [PII_REDACTED] x15: fffffffffffea0d0
   x14: [PII_REDACTED] x13: 284e4f5f4e524157 x12: 5f534b434f4c5f47
   x11: ffff80000a386aa8 x10: [PII_REDACTED] x9 : ffff80000cfab610
   x8 : [PII_REDACTED] x7 : [PII_REDACTED] x6 : [PII_REDACTED]
   x5 : [PII_REDACTED] x4 : ffff8000081ad904 x3 : [PII_REDACTED]
   x2 : ffff0000801db4c0 x1 : ffff80000cfabb80 x0 : ffff000081aceb58
   Call trace:
    drm_modeset_lock+0xf8/0x154
    drm_atomic_get_private_obj_state+0x84/0x170
    mdp5_get_global_state+0x54/0x6c
    mdp5_pipe_release+0x2c/0xd4
    mdp5_plane_atomic_check+0x2ec/0x414
    drm_atomic_helper_check_planes+0xd8/0x210
    drm_atomic_helper_check+0x54/0xb0
    ...
   ---[ end trace [PII_REDACTED] ]---
   drm_modeset_lock attempting to lock a contended lock without backoff:
      drm_modeset_lock+0x148/0x154
      mdp5_get_global_state+0x30/0x6c
      mdp5_pipe_release+0x2c/0xd4
      mdp5_plane_atomic_check+0x290/0x414
      drm_atomic_helper_check_planes+0xd8/0x210
      drm_atomic_helper_check+0x54/0xb0
      drm_atomic_check_only+0x4b0/0x8f4
      drm_atomic_commit+0x68/0xe0

Patchwork: https://patchwork.freedesktop.org/patch/492701/
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/0b07f28c23ff50a7fa5dbc3f6b3b6bd53ac9fc70; https://git.kernel.org/stable/c/247f2934324f9a18d18df24ea4bfcc7d4631d0ef; https://git.kernel.org/stable/c/2e34d6c8180a398de6448a93df25068bf3062042
CVE: CVE-2022-50174
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

net: hinic: avoid kernel hung in hinic_get_stats64()

When using hinic device as a bond slave device, and reading device stats
of master bond device, the kernel may hung.

The kernel panic calltrace as follows:
Kernel panic - not syncing: softlockup: hung tasks
Call trace:
  native_queued_spin_lock_slowpath+0x1ec/0x31c
  dev_get_stats+0x60/0xcc
  dev_seq_printf_stats+0x40/0x120
  dev_seq_show+0x1c/0x40
  seq_read_iter+0x3c8/0x4dc
  seq_read+0xe0/0x130
  proc_reg_read+0xa8/0xe0
  vfs_read+0xb0/0x1d4
  ksys_read+0x70/0xfc
  __arm64_sys_read+0x20/0x30
  el0_svc_common+0x88/0x234
  do_el0_svc+0x2c/0x90
  el0_svc+0x1c/0x30
  el0_sync_handler+0xa8/0xb0
  el0_sync+0x148/0x180

And the calltrace of task that actually caused kernel hungs as follows:
  __switch_to+124
  __schedule+548
  schedule+72
  schedule_timeout+348
  __down_common+188
  __down+24
  down+104
  hinic_get_stats64+44 [hinic]
  dev_get_stats+92
  bond_get_stats+172 [bonding]
  dev_get_stats+92
  dev_seq_printf_stats+60
  dev_seq_show+24
  seq_read_iter+964
  seq_read+220
  proc_reg_read+164
  vfs_read+172
  ksys_read+108
  __arm64_sys_read+28
  el0_svc_common+132
  do_el0_svc+40
  el0_svc+24
  el0_sync_handler+164
  el0_sync+324

When getting device stats from bond, kernel will call bond_get_stats().
It first holds the spinlock bond->stats_lock, and then call
hinic_get_stats64() to collect hinic device's stats.
However, hinic_get_stats64() calls `down(&nic_dev->mgmt_lock)` to
protect its critical section, which may schedule current task out.
And if system is under high pressure, the task cannot be woken up
immediately, which eventually triggers kernel hung panic.

Since previous patch has replaced hinic_dev.tx_stats/rx_stats with local
variable in hinic_get_stats64(), there is nothing need to be protected
by lock, so just removing down()/up() is ok.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/3ba59bbe4f306bb6ee15753db0a40564c0eb7909; https://git.kernel.org/stable/c/693f31dc91568e61047fd2980a8235e856cd9ce8; https://git.kernel.org/stable/c/98f9fcdee35add80505b6c73f72de5f750d5c03c
CVE: CVE-2022-50175
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

media: tw686x: Fix memory leak in tw686x_video_init

video_device_alloc() allocates memory for vdev,
when video_register_device() fails, it doesn't release the memory and
leads to memory leak, call video_device_release() to fix this.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/0597bcf774896a002edcc7934a9cdbb932b66702; https://git.kernel.org/stable/c/611f86965df013d6021e6cd0d155b1734ad2cf21; https://git.kernel.org/stable/c/8b412db51db24dfba22c96948580d4a12f831397
CVE: CVE-2022-50176
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/mcde: Fix refcount leak in mcde_dsi_bind

Every iteration of for_each_available_child_of_node() decrements
the reference counter of the previous node. There is no decrement
when break out from the loop and results in refcount leak.
Add missing of_node_put() to fix this.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3123ae6fdd4013d24a3a4877084b14e917faae5c; https://git.kernel.org/stable/c/32c827e30bb44ae809950a9efab59e98e44d30e5; https://git.kernel.org/stable/c/3a149169e4a2f9127022fec6ef5d71b4e804b3b9
CVE: CVE-2022-50178
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: rtw89: 8852a: rfk: fix div 0 exception

The DPK is a kind of RF calibration whose algorithm is to fine tune
parameters and calibrate, and check the result. If the result isn't good
enough, it could adjust parameters and try again.

This issue is to read and show the result, but it could be a negative
calibration result that causes divisor 0 and core dump. So, fix it by
phy_div() that does division only if divisor isn't zero; otherwise,
zero is adopted.

  divide error: 0000 [#1] PREEMPT SMP NOPTI
  CPU: 1 PID: 728 Comm: wpa_supplicant Not tainted 5.10.114-16019-g462a1661811a #1 <HASH:d024 28>
  RIP: 0010:rtw8852a_dpk+0x14ae/0x288f [rtw89_core]
  RSP: 0018:ffffa9bb412a7520 EFLAGS: 00010246
  RAX: [PII_REDACTED] RBX: [PII_REDACTED] RCX: [PII_REDACTED]
  RDX: [PII_REDACTED] RSI:[PII_REDACTED]0180fc RDI: ffffa141d01023c0
  RBP: ffffa9bb412a76a0 R08: [PII_REDACTED] R09: 00000000ffffff92
  R10: ffffffffc0292de3 R11: ffffffffc00d2f51 R12: [PII_REDACTED]
  R13: ffffa141d01023c0 R14: ffffffffc0290250 R15: ffffa141d0102638
  FS:  00007fa99f5c2740(0000) GS:ffffa142e5e80000(0000) knlGS:[PII_REDACTED]
  CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
  CR2:[PII_REDACTED]e8e010 CR3:[PII_REDACTED]d2c000 CR4:[PII_REDACTED]750ee0
  PKRU: 55555554
  Call Trace:
   rtw89_core_sta_add+0x95/0x9c [rtw89_core <HASH:d239 29>]
   rtw89_ops_sta_state+0x5d/0x108 [rtw89_core <HASH:d239 29>]
   drv_sta_state+0x115/0x66f [mac80211 <HASH:81fe 30>]
   sta_info_insert_rcu+0x45c/0x713 [mac80211 <HASH:81fe 30>]
   sta_info_insert+0xf/0x1b [mac80211 <HASH:81fe 30>]
   ieee80211_prep_connection+0x9d6/0xb0c [mac80211 <HASH:81fe 30>]
   ieee80211_mgd_auth+0x2aa/0x352 [mac80211 <HASH:81fe 30>]
   cfg80211_mlme_auth+0x160/0x1f6 [cfg80211 <HASH:00cd 31>]
   nl80211_authenticate+0x2e5/0x306 [cfg80211 <HASH:00cd 31>]
   genl_rcv_msg+0x371/0x3a1
   ? nl80211_stop_sched_scan+0xe5/0xe5 [cfg80211 <HASH:00cd 31>]
   ? genl_rcv+0x36/0x36
   netlink_rcv_skb+0x8a/0xf9
   genl_rcv+0x28/0x36
   netlink_unicast+0x27b/0x3a0
   netlink_sendmsg+0x2aa/0x469
   sock_sendmsg_nosec+0x49/0x4d
   ____sys_sendmsg+0xe5/0x213
   __sys_sendmsg+0xec/0x157
   ? syscall_enter_from_user_mode+0xd7/0x116
   do_syscall_64+0x43/0x55
   entry_SYSCALL_64_after_hwframe+0x44/0xa9
  RIP: 0033:0x7fa99f6e689b
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-369
References: https://git.kernel.org/stable/c/065e83ac83c0c0e615b96947145c85c4bd76c09a; https://git.kernel.org/stable/c/5abc81a138f873ab55223ec674afc3a3f945d60f; https://git.kernel.org/stable/c/683a4647a7a3044868cfdc14c117525091b9fa0c
CVE: CVE-2022-50179
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

ath9k: fix use-after-free in ath9k_hif_usb_rx_cb

Syzbot reported use-after-free Read in ath9k_hif_usb_rx_cb() [0]. The
problem was in incorrect htc_handle->drv_priv initialization.

Probable call trace which can trigger use-after-free:

ath9k_htc_probe_device()
  /* htc_handle->drv_priv = priv; */
  ath9k_htc_wait_for_target()      <--- Failed
  ieee80211_free_hw()		   <--- priv pointer is freed

<IRQ>
...
ath9k_hif_usb_rx_cb()
  ath9k_hif_usb_rx_stream()
   RX_STAT_INC()		<--- htc_handle->drv_priv access

In order to not add fancy protection for drv_priv we can move
htc_handle->drv_priv initialization at the end of the
ath9k_htc_probe_device() and add helper macro to make
all *_STAT_* macros NULL safe, since syzbot has reported related NULL
deref in that macros [1]
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/03ca957c5f7b55660957eda20b5db4110319ac7a; https://git.kernel.org/stable/c/0ac4827f78c7ffe8eef074bc010e7e34bc22f533; https://git.kernel.org/stable/c/62bc1ea5c7401d77eaf73d0c6a15f3d2e742856e
CVE: CVE-2022-50180
Published: 2025-06-18
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2022-50181
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

virtio-gpu: fix a missing check to avoid NULL dereference

'cache_ent' could be set NULL inside virtio_gpu_cmd_get_capset()
and it will lead to a NULL dereference by a lately use of it
(i.e., ptr = cache_ent->caps_cache). Fix it with a NULL check.


[ kraxel: minor codestyle fixup ]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/259773fc874258606c0121767a4a27466ff337eb; https://git.kernel.org/stable/c/367882a5a9448b5e1ba[PII_REDACTED]92d614cb96c; https://git.kernel.org/stable/c/39caef09666c1d8274abf9472c72bcac236dc5fb
CVE: CVE-2022-50182
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

media: imx-jpeg: Align upwards buffer size

The hardware can support any image size WxH,
with arbitrary W (image width) and H (image height) dimensions.

Align upwards buffer size for both encoder and decoder.
and leave the picture resolution unchanged.

For decoder, the risk of memory out of bounds can be avoided.
For both encoder and decoder, the driver will lift the limitation of
resolution alignment.

For example, the decoder can support jpeg whose resolution is 227x149
the encoder can support nv12 1080P, won't change it to 1920x1072.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/447795ffb17cd60bb544e0abfc9399e180a14a2f; https://git.kernel.org/stable/c/73d1836ed[PII_REDACTED]b787745cb8c5857a2661c; https://git.kernel.org/stable/c/9ae2d729de6350c53a06c57782751d84eb2c08d9
CVE: CVE-2022-50183
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/meson: encoder_cvbs: Fix refcount leak in meson_encoder_cvbs_init

of_graph_get_remote_node() returns remote device nodepointer with
refcount incremented, we should use of_node_put() on it when done.
Add missing of_node_put() to avoid refcount leak.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/51c36411ae27bf5f06c43462d2de2d4947ed33ea; https://git.kernel.org/stable/c/7d255ddbbf679aa47e041cbf68520fd985ed2279; https://git.kernel.org/stable/c/bb5ac08d5bd8626c318bd80a5063263daab8fdb6
CVE: CVE-2022-50184
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/meson: encoder_hdmi: Fix refcount leak in meson_encoder_hdmi_init

of_graph_get_remote_node() returns remote device nodepointer with
refcount incremented, we should use of_node_put() on it when done.
Add missing of_node_put() to avoid refcount leak.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/013e67e7dd898170cbf54981cf1ed7616f822566; https://git.kernel.org/stable/c/275fed7142fff5b27e176e[PII_REDACTED]5043de5c; https://git.kernel.org/stable/c/994bc82df85564d948037f1dfdd47c907e8a084b
CVE: CVE-2022-50185
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/radeon: fix potential buffer overflow in ni_set_mc_special_registers()

The last case label can write two buffers 'mc_reg_address[j]' and
'mc_data[j]' with 'j' offset equal to SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE
since there are no checks for this value in both case labels after the
last 'j++'.

Instead of changing '>' to '>=' there, add the bounds check at the start
of the second 'case' (the first one already has it).

Also, remove redundant last checks for 'j' index bigger than array size.
The expression is always false. Moreover, before or after the patch
'table->last' can be equal to SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE and it
seems it can be a valid value.

Detected using the static analysis tool - Svace.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/136f614931a2bb73616b292cf542da3a18daefd5; https://git.kernel.org/stable/c/1f341053852be76f82610ce47a505d930512f05c; https://git.kernel.org/stable/c/782e413e38dffd37cc85b08b1ccb982adb4a93ce