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

md/bitmap: don't set sb values if can't pass sanity check

If bitmap area contains invalid data, kernel will crash then mdadm
triggers "Segmentation fault".
This is cluster-md speical bug. In non-clustered env, mdadm will
handle broken metadata case. In clustered array, only kernel space
handles bitmap slot info. But even this bug only happened in clustered
env, current sanity check is wrong, the code should be changed.

How to trigger: (faulty injection)

dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sda
dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sdb
mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sda /dev/sdb
mdadm -Ss
echo aaa > magic.txt
 == below modifying slot 2 bitmap data ==
dd if=magic.txt of=/dev/sda seek=16384 bs=1 count=3 <== destroy magic
dd if=/dev/zero of=/dev/sda seek=16436 bs=1 count=4 <== ZERO chunksize
mdadm -A /dev/md0 /dev/sda /dev/sdb
 == kernel crashes. mdadm outputs "Segmentation fault" ==

Reason of kernel crash:

In md_bitmap_read_sb (called by md_bitmap_create), bad bitmap magic didn't
block chunksize assignment, and zero value made DIV_ROUND_UP_SECTOR_T()
trigger "divide error".

Crash log:

kernel: md: md0 stopped.
kernel: md/raid1:md0: not clean -- starting background reconstruction
kernel: md/raid1:md0: active with 2 out of 2 mirrors
kernel: dlm: ... ...
kernel: md-cluster: Joined cluster 44810aba-38bb-e6b8-daca-bc97a0b254aa slot 1
kernel: md0: invalid bitmap file superblock: bad magic
kernel: md_bitmap_copy_from_slot can't get bitmap from slot 2
kernel: md-cluster: Could not gather bitmaps from slot 2
kernel: divide error: 0000 [#1] SMP NOPTI
kernel: CPU: 0 PID: 1603 Comm: mdadm Not tainted 5.14.6-1-default
kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
kernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 [md_mod]
kernel: RSP: 0018:ffffc22ac0843ba0 EFLAGS: 00010246
kernel: ... ...
kernel: Call Trace:
kernel:  ? dlm_lock_sync+0xd0/0xd0 [md_cluster 77fe..7a0]
kernel:  md_bitmap_copy_from_slot+0x2c/0x290 [md_mod 24ea..d3a]
kernel:  load_bitmaps+0xec/0x210 [md_cluster 77fe..7a0]
kernel:  md_bitmap_load+0x81/0x1e0 [md_mod 24ea..d3a]
kernel:  do_md_run+0x30/0x100 [md_mod 24ea..d3a]
kernel:  md_ioctl+0x1290/0x15a0 [md_mod 24ea....d3a]
kernel:  ? mddev_unlock+0xaa/0x130 [md_mod 24ea..d3a]
kernel:  ? blkdev_ioctl+0xb1/0x2b0
kernel:  block_ioctl+0x3b/0x40
kernel:  __x64_sys_ioctl+0x7f/0xb0
kernel:  do_syscall_64+0x59/0x80
kernel:  ? exit_to_user_mode_prepare+0x1ab/0x230
kernel:  ? syscall_exit_to_user_mode+0x18/0x40
kernel:  ? do_syscall_64+0x69/0x80
kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xae
kernel: RIP: 0033:0x7f4a15fa722b
kernel: ... ...
kernel: ---[ end trace 8afa7612f559c868 ]---
kernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 [md_mod]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0959aa00f9765bd8c654b1365012e41b51c733cc; https://git.kernel.org/stable/c/27f672af28a8e9b783ff7f0eaf7ef2fbd5a2f4ba; https://git.kernel.org/stable/c/422e8f7ba1e08c8e0e88d375bcb550bc2bbfe96d
CVE: CVE-2022-49527
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

media: venus: hfi: avoid null dereference in deinit

If venus_probe fails at pm_runtime_put_sync the error handling first
calls hfi_destroy and afterwards hfi_core_deinit. As hfi_destroy sets
core->ops to NULL, hfi_core_deinit cannot call the core_deinit function
anymore.

Avoid this null pointer derefence by skipping the call when necessary.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/0ac84ab50712879eac3c1dd[PII_REDACTED]a85d3d0; https://git.kernel.org/stable/c/0ed5a643b1a4a46b9b7bfba5d468c10cc30e1359; https://git.kernel.org/stable/c/2533acb652359c9e097dfa33587896af782e8a91
CVE: CVE-2022-49528
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

media: i2c: dw9714: Disable the regulator when the driver fails to probe

When the driver fails to probe, we will get the following splat:

[   59.305988] ------------[ cut here ]------------
[   59.306417] WARNING: CPU: 2 PID: 395 at drivers/regulator/core.c:2257 _regulator_put+0x3ec/0x4e0
[   59.310345] RIP: 0010:_regulator_put+0x3ec/0x4e0
[   59.318362] Call Trace:
[   59.318582]  <TASK>
[   59.318765]  regulator_put+0x1f/0x30
[   59.319058]  devres_release_group+0x319/0x3d0
[   59.319420]  i2c_device_probe+0x766/0x940

Fix this by disabling the regulator in error handling.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/02276e18defa2fccf16413b44440277d98c2b1ea; https://git.kernel.org/stable/c/fa83ea1de5b3efd87fe01408d5db1fd2ff4767fa
CVE: CVE-2022-49529
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu/pm: fix the null pointer while the smu is disabled

It needs to check if the pp_funcs is initialized while release the
context, otherwise it will trigger null pointer panic while the software
smu is not enabled.

[ 1109.404555] BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
[ 1109.404609] #PF: supervisor read access in kernel mode
[ 1109.404638] #PF: error_code(0x0000) - not-present page
[ 1109.404657] PGD 0 P4D 0
[ 1109.404672] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 1109.404701] CPU: 7 PID: 9150 Comm: amdgpu_test Tainted: G           OEL    5.16.0-custom #1
[ 1109.404732] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[ 1109.404765] RIP: 0010:amdgpu_dpm_force_performance_level+0x1d/0x170 [amdgpu]
[ 1109.405109] Code: 5d c3 44 8b a3 f0 80 00 00 eb e5 66 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 08 4c 8b b7 f0 7d 00 00 <49> 83 7e 78 00 0f 84 f2 00 00 00 80 bf 87 80 00 00 00 48 89 fb 0f
[ 1109.405176] RSP: 0018:ffffaf3083ad7c20 EFLAGS: 00010282
[ 1109.405203] RAX: [PII_REDACTED] RBX: ffff9796b1c14600 RCX: [PII_REDACTED]
[ 1109.405229] RDX: ffff97968591c8c0 RSI: [PII_REDACTED] RDI: ffff9796a3700000
[ 1109.405260] RBP: ffffaf3083ad7c50 R08: ffffffff9897de00 R09: ffff979688d9db60
[ 1109.405286] R10: [PII_REDACTED] R11: ffff979688d9db90 R12: [PII_REDACTED]
[ 1109.405316] R13: ffff9796a3700000 R14: [PII_REDACTED] R15: ffff9796a3708fc0
[ 1109.405345] FS:  00007ff055cff180(0000) GS:ffff9796bfdc0000(0000) knlGS:[PII_REDACTED]
[ 1109.405378] CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
[ 1109.405400] CR2: [PII_REDACTED] CR3: 000000000a394000 CR4:[PII_REDACTED]0506e0
[ 1109.405434] Call Trace:
[ 1109.405445]  <TASK>
[ 1109.405456]  ? delete_object_full+0x1d/0x20
[ 1109.405480]  amdgpu_ctx_set_stable_pstate+0x7c/0xa0 [amdgpu]
[ 1109.405698]  amdgpu_ctx_fini.part.0+0xcb/0x100 [amdgpu]
[ 1109.405911]  amdgpu_ctx_do_release+0x71/0x80 [amdgpu]
[ 1109.406121]  amdgpu_ctx_ioctl+0x52d/0x550 [amdgpu]
[ 1109.406327]  ? _raw_spin_unlock+0x1a/0x30
[ 1109.406354]  ? drm_gem_handle_delete+0x81/0xb0 [drm]
[ 1109.406400]  ? amdgpu_ctx_get_entity+0x2c0/0x2c0 [amdgpu]
[ 1109.406609]  drm_ioctl_kernel+0xb6/0x140 [drm]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/49ec3441aa5e5940f3e82dd2f0205b9c856e399d; https://git.kernel.org/stable/c/eea5c7b3390c6e006ba4cbd906447dd8cea8cfbf
CVE: CVE-2022-49530
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/pm: fix double free in si_parse_power_table()

In function si_parse_power_table(), array adev->pm.dpm.ps and its member
is allocated. If the allocation of each member fails, the array itself
is freed and returned with an error code. However, the array is later
freed again in si_dpm_fini() function which is called when the function
returns an error.

This leads to potential double free of the array adev->pm.dpm.ps, as
well as leak of its array members, since the members are not freed in
the allocation function and the array is not nulled when freed.
In addition adev->pm.dpm.num_ps, which keeps track of the allocated
array member, is not updated until the member allocation is
successfully finished, this could also lead to either use after free,
or uninitialized variable access in si_dpm_fini().

Fix this by postponing the free of the array until si_dpm_fini() and
increment adev->pm.dpm.num_ps everytime the array member is allocated.
CVSS Score: 7.8 (HIGH)
CWE: CWE-415, CWE-415
References: https://git.kernel.org/stable/c/[PII_REDACTED]505188f909d0c07c37a6623693b5c7; https://git.kernel.org/stable/c/43eb9b667b95f2a31c63e8949b0d2161b9be59c3; https://git.kernel.org/stable/c/6c5bdaa1325be7f04b79ea992ab216739192d342
CVE: CVE-2022-49531
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

loop: implement ->free_disk

Ensure that the lo_device which is stored in the gendisk private
data is valid until the gendisk is freed.  Currently the loop driver
uses a lot of effort to make sure a device is not freed when it is
still in use, but to to fix a potential deadlock this will be relaxed
a bit soon.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667, CWE-667
References: https://git.kernel.org/stable/c/aadd1443aae7fe8956e3b[PII_REDACTED]f034406a; https://git.kernel.org/stable/c/d2c7f56f8b5256d57f9e3fc7794c31361d43bdd9
CVE: CVE-2022-49532
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/virtio: fix NULL pointer dereference in virtio_gpu_conn_get_modes

drm_cvt_mode may return NULL and we should check it.

This bug is found by syzkaller:

FAULT_INJECTION stacktrace:
[  168.567394] FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 1
[  168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1
[  168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[  168.567408] Call trace:
[  168.567414]  dump_backtrace+0x0/0x310
[  168.567418]  show_stack+0x28/0x38
[  168.567423]  dump_stack+0xec/0x15c
[  168.567427]  should_fail+0x3ac/0x3d0
[  168.567437]  __should_failslab+0xb8/0x120
[  168.567441]  should_failslab+0x28/0xc0
[  168.567445]  kmem_cache_alloc_trace+0x50/0x640
[  168.567454]  drm_mode_create+0x40/0x90
[  168.567458]  drm_cvt_mode+0x48/0xc78
[  168.567477]  virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu]
[  168.567485]  drm_helper_probe_single_connector_modes+0x3a4/0xd80
[  168.567492]  drm_mode_getconnector+0x2e0/0xa70
[  168.567496]  drm_ioctl_kernel+0x11c/0x1d8
[  168.567514]  drm_ioctl+0x558/0x6d0
[  168.567522]  do_vfs_ioctl+0x160/0xf30
[  168.567525]  ksys_ioctl+0x98/0xd8
[  168.567530]  __arm64_sys_ioctl+0x50/0xc8
[  168.567536]  el0_svc_common+0xc8/0x320
[  168.567540]  el0_svc_handler+0xf8/0x160
[  168.567544]  el0_svc+0x10/0x218

KASAN stacktrace:
[  168.567561] BUG: KASAN: null-ptr-deref in virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]
[  168.567565] Read of size 4 at addr [PII_REDACTED] by task syz/6425
[  168.567566]
[  168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1
[  168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[  168.567575] Call trace:
[  168.567578]  dump_backtrace+0x0/0x310
[  168.567582]  show_stack+0x28/0x38
[  168.567586]  dump_stack+0xec/0x15c
[  168.567591]  kasan_report+0x244/0x2f0
[  168.567594]  __asan_load4+0x58/0xb0
[  168.567607]  virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]
[  168.567612]  drm_helper_probe_single_connector_modes+0x3a4/0xd80
[  168.567617]  drm_mode_getconnector+0x2e0/0xa70
[  168.567621]  drm_ioctl_kernel+0x11c/0x1d8
[  168.567624]  drm_ioctl+0x558/0x6d0
[  168.567628]  do_vfs_ioctl+0x160/0xf30
[  168.567632]  ksys_ioctl+0x98/0xd8
[  168.567636]  __arm64_sys_ioctl+0x50/0xc8
[  168.567641]  el0_svc_common+0xc8/0x320
[  168.567645]  el0_svc_handler+0xf8/0x160
[  168.567649]  el0_svc+0x10/0x218
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/0f8bc147a963686b7351aa35d1701124ffacac08; https://git.kernel.org/stable/c/194d250cdc4a40ccbd179afd522a9e[PII_REDACTED]; https://git.kernel.org/stable/c/32e10aabc287f09a148ff759bb9ce70b01b0012c
CVE: CVE-2022-49533
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ath11k: Change max no of active probe SSID and BSSID to fw capability

The maximum number of SSIDs in a for active probe requests is currently
reported as 16 (WLAN_SCAN_PARAMS_MAX_SSID) when registering the driver.
The scan_req_params structure only has the capacity to hold 10 SSIDs.
This leads to a buffer overflow which can be triggered from
wpa_supplicant in userspace. When copying the SSIDs into the
scan_req_params structure in the ath11k_mac_op_hw_scan route, it can
overwrite the extraie pointer.

Firmware supports 16 ssid * 4 bssid, for each ssid 4 bssid combo probe
request will be sent, so totally 64 probe requests supported. So
set both max ssid and bssid to 16 and 4 respectively. Remove the
redundant macros of ssid and bssid.

Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01300-QCAHKSWPL_SILICONZ-1
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/210505788f1d243232e21ef660efcd4838890ce8; https://git.kernel.org/stable/c/50dc9ce9f80554a88e33b73c30851acf2be36ed3; https://git.kernel.org/stable/c/ec5dfa1d66f2f71a48dab027d26a9fa78eb0f58f
CVE: CVE-2022-49534
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Protect memory leak for NPIV ports sending PLOGI_RJT

There is a potential memory leak in lpfc_ignore_els_cmpl() and
lpfc_els_rsp_reject() that was allocated from NPIV PLOGI_RJT
(lpfc_rcv_plogi()'s login_mbox).

Check if cmdiocb->context_un.mbox was allocated in lpfc_ignore_els_cmpl(),
and then free it back to phba->mbox_mem_pool along with mbox->ctx_buf for
service parameters.

For lpfc_els_rsp_reject() failure, free both the ctx_buf for service
parameters and the login_mbox.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/672d1cb40551ea9c95efad43ab6d45e4ab4e015f; https://git.kernel.org/stable/c/c00df0f34a6d5e14da379f96ea67e501ce67b002
CVE: CVE-2022-49535
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Fix null pointer dereference after failing to issue FLOGI and PLOGI

If lpfc_issue_els_flogi() fails and returns non-zero status, the node
reference count is decremented to trigger the release of the nodelist
structure. However, if there is a prior registration or dev-loss-evt work
pending, the node may be released prematurely.  When dev-loss-evt
completes, the released node is referenced causing a use-after-free null
pointer dereference.

Similarly, when processing non-zero ELS PLOGI completion status in
lpfc_cmpl_els_plogi(), the ndlp flags are checked for a transport
registration before triggering node removal.  If dev-loss-evt work is
pending, the node may be released prematurely and a subsequent call to
lpfc_dev_loss_tmo_handler() results in a use after free ndlp dereference.

Add test for pending dev-loss before decrementing the node reference count
for FLOGI, PLOGI, PRLI, and ADISC handling.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/10663ebec0ad5c78493a0dd34c9ee4d73d7ca0df; https://git.kernel.org/stable/c/577a942df3de2666f6947bdd3a5c9e8d30073424; https://git.kernel.org/stable/c/c7dc74ab7975c9b96284abfe4cca756d75fa4604
CVE: CVE-2022-49536
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Fix SCSI I/O completion and abort handler deadlock

During stress I/O tests with 500+ vports, hard LOCKUP call traces are
observed.

CPU A:
 native_queued_spin_lock_slowpath+0x192
 _raw_spin_lock_irqsave+0x32
 lpfc_handle_fcp_err+0x4c6
 lpfc_fcp_io_cmd_wqe_cmpl+0x964
 lpfc_sli4_fp_handle_cqe+0x266
 __lpfc_sli4_process_cq+0x105
 __lpfc_sli4_hba_process_cq+0x3c
 lpfc_cq_poll_hdler+0x16
 irq_poll_softirq+0x76
 __softirqentry_text_start+0xe4
 irq_exit+0xf7
 do_IRQ+0x7f

CPU B:
 native_queued_spin_lock_slowpath+0x5b
 _raw_spin_lock+0x1c
 lpfc_abort_handler+0x13e
 scmd_eh_abort_handler+0x85
 process_one_work+0x1a7
 worker_thread+0x30
 kthread+0x112
 ret_from_fork+0x1f

Diagram of lockup:

CPUA                            CPUB
----                            ----
lpfc_cmd->buf_lock
                            phba->hbalock
                            lpfc_cmd->buf_lock
phba->hbalock

Fix by reordering the taking of the lpfc_cmd->buf_lock and phba->hbalock in
lpfc_abort_handler routine so that it tries to take the lpfc_cmd->buf_lock
first before phba->hbalock.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667, CWE-667
References: https://git.kernel.org/stable/c/03cbbd7c2f5ee288f648f4aeedc765a181188553; https://git.kernel.org/stable/c/0c4eed901285b9cae36a622f32bea3e92490da6c; https://git.kernel.org/stable/c/21c0d469349957b5dc811c41200a2a998996ca8d
CVE: CVE-2022-49537
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Fix call trace observed during I/O with CMF enabled

The following was seen with CMF enabled:

BUG: using smp_processor_id() in preemptible
code: systemd-udevd/31711
kernel: caller is lpfc_update_cmf_cmd+0x214/0x420  [lpfc]
kernel: CPU: 12 PID: 31711 Comm: systemd-udevd
kernel: Call Trace:
kernel: <TASK>
kernel: dump_stack_lvl+0x44/0x57
kernel: check_preemption_disabled+0xbf/0xe0
kernel: lpfc_update_cmf_cmd+0x214/0x420 [lpfc]
kernel: lpfc_nvme_fcp_io_submit+0x23b4/0x4df0 [lpfc]

this_cpu_ptr() calls smp_processor_id() in a preemptible context.

Fix by using per_cpu_ptr() with raw_smp_processor_id() instead.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/517e0835cfb2007713ff16c4fb8479f08b16aec7; https://git.kernel.org/stable/c/ae373d66c427812754db5292eb1481b181daf9ce; https://git.kernel.org/stable/c/cd7f899de4b1b829125d72ee6fbfd878b637b815
CVE: CVE-2022-49538
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: jack: Access input_dev under mutex

It is possible when using ASoC that input_dev is unregistered while
calling snd_jack_report, which causes NULL pointer dereference.
In order to prevent this serialize access to input_dev using mutex lock.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/1b6a6fc5280e97559287b61eade2d4b363e836f2; https://git.kernel.org/stable/c/582aea6084cc59fec881204f026816d1219f2348; https://git.kernel.org/stable/c/5cc6f623f4818c7d7e9e966a45ebf324901ca9c5
CVE: CVE-2022-49539
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

rtw89: ser: fix CAM leaks occurring in L2 reset

The CAM, meaning address CAM and bssid CAM here, will get leaks during
SER (system error recover) L2 reset process and ieee80211_restart_hw()
which is called by L2 reset process eventually.

The normal flow would be like
-> add interface (acquire 1)
-> enter ips (release 1)
-> leave ips (acquire 1)
-> connection (occupy 1) <(A) 1 leak after L2 reset if non-sec connection>

The ieee80211_restart_hw() flow (under connection)
-> ieee80211 reconfig
-> add interface (acquire 1)
-> leave ips (acquire 1)
-> connection (occupy (A) + 2) <(B) 1 more leak>

Originally, CAM is released before HW restart only if connection is under
security. Now, release CAM whatever connection it is to fix leak in (A).
OTOH, check if CAM is already valid to avoid acquiring multiple times to
fix (B).

Besides, if AP mode, release address CAM of all stations before HW restart.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/b169f877f001a474fb89939842c390518160bcc5; https://git.kernel.org/stable/c/f6aff772c[PII_REDACTED]618d86aafb53e5d3ae161
CVE: CVE-2022-49541
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

cifs: fix potential double free during failed mount

RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=2088799
CVSS Score: 7.8 (HIGH)
CWE: CWE-415, CWE-415
References: https://git.kernel.org/stable/c/8378a51e3f8140f60901fb27208cc7a6e47047b5; https://git.kernel.org/stable/c/9a167fc440e5693c1cdd7f07071e05658bd9d89d; https://git.kernel.org/stable/c/ce0008a0e410cdd95f0d8cd81b2902ec10a660c4
CVE: CVE-2022-49542
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Move cfg_log_verbose check before calling lpfc_dmp_dbg()

In an attempt to log message 0126 with LOG_TRACE_EVENT, the following hard
lockup call trace hangs the system.

Call Trace:
 _raw_spin_lock_irqsave+0x32/0x40
 lpfc_dmp_dbg.part.32+0x28/0x220 [lpfc]
 lpfc_cmpl_els_fdisc+0x145/0x460 [lpfc]
 lpfc_sli_cancel_jobs+0x92/0xd0 [lpfc]
 lpfc_els_flush_cmd+0x43c/0x670 [lpfc]
 lpfc_els_flush_all_cmd+0x37/0x60 [lpfc]
 lpfc_sli4_async_event_proc+0x956/0x1720 [lpfc]
 lpfc_do_work+0x1485/0x1d70 [lpfc]
 kthread+0x112/0x130
 ret_from_fork+0x1f/0x40
Kernel panic - not syncing: Hard LOCKUP

The same CPU tries to claim the phba->port_list_lock twice.

Move the cfg_log_verbose checks as part of the lpfc_printf_vlog() and
lpfc_printf_log() macros before calling lpfc_dmp_dbg().  There is no need
to take the phba->port_list_lock within lpfc_dmp_dbg().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667, CWE-667
References: https://git.kernel.org/stable/c/09c772557a4fd9490fed1bfb133268313ea22213; https://git.kernel.org/stable/c/271725e4028559ae7974d762a8467dc9de412f2e; https://git.kernel.org/stable/c/cc6501afccec55b8b6c90584cbf71f1fefa77d1e
CVE: CVE-2022-49544
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ipw2x00: Fix potential NULL dereference in libipw_xmit()

crypt and crypt->ops could be null, so we need to checking null
before dereference
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/167affc11781d7d35c4c3a7630a549ac74dd0b21; https://git.kernel.org/stable/c/1ff6b0727c8988f25eeb670b6c038c1120bb58dd; https://git.kernel.org/stable/c/48d4a820fd33f012e5f63735a59d15b5a3882882
CVE: CVE-2022-49545
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: usb-audio: Cancel pending work at closing a MIDI substream

At closing a USB MIDI output substream, there might be still a pending
work, which would eventually access the rawmidi runtime object that is
being released.  For fixing the race, make sure to cancel the pending
work at closing.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0125de38122f0f66bf61336158d12a1aabfe6425; https://git.kernel.org/stable/c/11868ca[PII_REDACTED]9c2575b0d6508ef8e9c4291; https://git.kernel.org/stable/c/40bdb5ec957aca5c5c1924602bef6b0ab18e22d3