deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2023-53052
Published: 2025-05-02
Description: In the Linux kernel, the following vulnerability has been resolved:

cifs: fix use-after-free bug in refresh_cache_worker()

The UAF bug occurred because we were putting DFS root sessions in
cifs_umount() while DFS cache refresher was being executed.

Make DFS root sessions have same lifetime as DFS tcons so we can avoid
the use-after-free bug is DFS cache refresher and other places that
require IPCs to get new DFS referrals on.  Also, get rid of mount
group handling in DFS cache as we no longer need it.

This fixes below use-after-free bug catched by KASAN

[ 379.946955] BUG: KASAN: use-after-free in __refresh_tcon.isra.0+0x10b/0xc10 [cifs]
[ 379.947642] Read of size 8 at addr ffff888018f57030 by task kworker/u4:3/56
[ 379.948096]
[ 379.948208] CPU: 0 PID: 56 Comm: kworker/u4:3 Not tainted 6.2.0-rc7-lku #23
[ 379.948661] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.16.0-0-gd239552-rebuilt.opensuse.org 04/01/2014
[ 379.949368] Workqueue: cifs-dfscache refresh_cache_worker [cifs]
[ 379.949942] Call Trace:
[ 379.950113] <TASK>
[ 379.950260] dump_stack_lvl+0x50/0x67
[ 379.950510] print_report+0x16a/0x48e
[ 379.950759] ? __virt_addr_valid+0xd8/0x160
[ 379.951040] ? __phys_addr+0x41/0x80
[ 379.951285] kasan_report+0xdb/0x110
[ 379.951533] ? __refresh_tcon.isra.0+0x10b/0xc10 [cifs]
[ 379.952056] ? __refresh_tcon.isra.0+0x10b/0xc10 [cifs]
[ 379.952585] __refresh_tcon.isra.0+0x10b/0xc10 [cifs]
[ 379.953096] ? __pfx___refresh_tcon.isra.0+0x10/0x10 [cifs]
[ 379.953637] ? __pfx___mutex_lock+0x10/0x10
[ 379.953915] ? lock_release+0xb6/0x720
[ 379.954167] ? __pfx_lock_acquire+0x10/0x10
[ 379.954443] ? refresh_cache_worker+0x34e/0x6d0 [cifs]
[ 379.954960] ? __pfx_wb_workfn+0x10/0x10
[ 379.955239] refresh_cache_worker+0x4ad/0x6d0 [cifs]
[ 379.955755] ? __pfx_refresh_cache_worker+0x10/0x10 [cifs]
[ 379.956323] ? __pfx_lock_acquired+0x10/0x10
[ 379.956615] ? read_word_at_a_time+0xe/0x20
[ 379.956898] ? lockdep_hardirqs_on_prepare+0x12/0x220
[ 379.957235] process_one_work+0x535/0x990
[ 379.957509] ? __pfx_process_one_work+0x10/0x10
[ 379.957812] ? lock_acquired+0xb7/0x5f0
[ 379.958069] ? __list_add_valid+0x37/0xd0
[ 379.958341] ? __list_add_valid+0x37/0xd0
[ 379.958611] worker_thread+0x8e/0x630
[ 379.958861] ? __pfx_worker_thread+0x10/0x10
[ 379.959148] kthread+0x17d/0x1b0
[ 379.959369] ? __pfx_kthread+0x10/0x10
[ 379.959630] ret_from_fork+0x2c/0x50
[ 379.959879] </TASK>
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/396935de145589c8bfe552fa03a5e[PII_REDACTED]9; https://git.kernel.org/stable/c/5a89d81c1a3c152837ea204fd29572228e54ce0b
CVE: CVE-2023-53054
Published: 2025-05-02
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: dwc2: fix a devres leak in hw_enable upon suspend resume

Each time the platform goes to low power, PM suspend / resume routines
call: __dwc2_lowlevel_hw_enable -> devm_add_action_or_reset().
This adds a new devres each time.
This may also happen at runtime, as dwc2_lowlevel_hw_enable() can be
called from udc_start().

This can be seen with tracing:
- echo 1 > /sys/kernel/debug/tracing/events/dev/devres_log/enable
- go to low power
- cat /sys/kernel/debug/tracing/trace

A new "ADD" entry is found upon each low power cycle:
... devres_log: 49000000.usb-otg ADD 82a13bba devm_action_release (8 bytes)
... devres_log: 49000000.usb-otg ADD 49889daf devm_action_release (8 bytes)
...

A second issue is addressed here:
- regulator_bulk_enable() is called upon each PM cycle (suspend/resume).
- regulator_bulk_disable() never gets called.

So the reference count for these regulators constantly increase, by one
upon each low power cycle, due to missing regulator_bulk_disable() call
in __dwc2_lowlevel_hw_disable().

The original fix that introduced the devm_add_action_or_reset() call,
fixed an issue during probe, that happens due to other errors in
dwc2_driver_probe() -> dwc2_core_reset(). Then the probe fails without
disabling regulators, when dr_mode == USB_DR_MODE_PERIPHERAL.

Rather fix the error path: disable all the low level hardware in the
error path, by using the "hsotg->ll_hw_enabled" flag. Checking dr_mode
has been introduced to avoid a dual call to dwc2_lowlevel_hw_disable().
"ll_hw_enabled" should achieve the same (and is used currently in the
remove() routine).
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/1f01027c51eb16145e8e07fafea3ca07ef102d06; https://git.kernel.org/stable/c/6485fc381b6528b6f547ee1ff10bdbcbe31a6e4c; https://git.kernel.org/stable/c/cba76e1fb896b573f09f51aa299223276a77bc90
CVE: CVE-2023-53055
Published: 2025-05-02
Description: In the Linux kernel, the following vulnerability has been resolved:

fscrypt: destroy keyring after security_sb_delete()

fscrypt_destroy_keyring() must be called after all potentially-encrypted
inodes were evicted; otherwise it cannot safely destroy the keyring.
Since inodes that are in-use by the Landlock LSM don't get evicted until
security_sb_delete(), this means that fscrypt_destroy_keyring() must be
called *after* security_sb_delete().

This fixes a WARN_ON followed by a NULL dereference, only possible if
Landlock was being used on encrypted files.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/497ab5d9c7852dfedab2c9de75e41b60e54b7c5d; https://git.kernel.org/stable/c/992a3f3e8a0c92151dfdf65fc85567c865fd558a; https://git.kernel.org/stable/c/ccb820dc7d2236b1af0d54ae038a27b5b6d5ae5a
CVE: CVE-2023-53056
Published: 2025-05-02
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: qla2xxx: Synchronize the IOCB count to be in order

A system hang was observed with the following call trace:

BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 15 PID: 86747 Comm: nvme Kdump: loaded Not tainted 6.2.0+ #1
Hardware name: Dell Inc. PowerEdge R6515/04F3CJ, BIOS 2.7.3 03/31/2022
RIP: 0010:__wake_up_common+0x55/0x190
Code: 41 f6 01 04 0f 85 b2 00 00 00 48 8b 43 08 4c 8d
      40 e8 48 8d 43 08 48 89 04 24 48 89 c6\
      49 8d 40 18 48 39 c6 0f 84 e9 00 00 00 <49> 8b 40 18 89 6c 24 14 31
      ed 4c 8d 60 e8 41 8b 18 f6 c3 04 75 5d
RSP: 0018:ffffb05a82afbba0 EFLAGS: 00010082
RAX: [PII_REDACTED] RBX: ffff8f9b83a00018 RCX: [PII_REDACTED]
RDX: [PII_REDACTED] RSI: ffff8f9b83a00020 RDI: ffff8f9b83a00018
RBP: [PII_REDACTED] R08: ffffffffffffffe8 R09: ffffb05a82afbbf8
R10: 70735f[PII_REDACTED] R11: 5f[PII_REDACTED]6c71 R12: [PII_REDACTED]
R13: [PII_REDACTED] R14: [PII_REDACTED] R15: [PII_REDACTED]
FS:  00007f815cf4c740(0000) GS:ffff8f9eeed80000(0000)
	knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: [PII_REDACTED] CR3:[PII_REDACTED]33a000 CR4:[PII_REDACTED]350ee0
Call Trace:
    <TASK>
    __wake_up_common_lock+0x83/0xd0
    qla_nvme_ls_req+0x21b/0x2b0 [qla2xxx]
    __nvme_fc_send_ls_req+0x1b5/0x350 [nvme_fc]
    nvme_fc_xmt_disconnect_assoc+0xca/0x110 [nvme_fc]
    nvme_fc_delete_association+0x1bf/0x220 [nvme_fc]
    ? nvme_remove_namespaces+0x9f/0x140 [nvme_core]
    nvme_do_delete_ctrl+0x5b/0xa0 [nvme_core]
    nvme_sysfs_delete+0x5f/0x70 [nvme_core]
    kernfs_fop_write_iter+0x12b/0x1c0
    vfs_write+0x2a3/0x3b0
    ksys_write+0x5f/0xe0
    do_syscall_64+0x5c/0x90
    ? syscall_exit_work+0x103/0x130
    ? syscall_exit_to_user_mode+0x12/0x30
    ? do_syscall_64+0x69/0x90
    ? exit_to_user_mode_loop+0xd0/0x130
    ? exit_to_user_mode_prepare+0xec/0x100
    ? syscall_exit_to_user_mode+0x12/0x30
    ? do_syscall_64+0x69/0x90
    ? syscall_exit_to_user_mode+0x12/0x30
    ? do_syscall_64+0x69/0x90
    entry_SYSCALL_64_after_hwframe+0x72/0xdc
    RIP: 0033:0x7f815cd3eb97

The IOCB counts are out of order and that would block any commands from
going out and subsequently hang the system. Synchronize the IOCB count to
be in correct order.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/6295b3ec64a3623fa96869ffb7cf17d0b3c92035; https://git.kernel.org/stable/c/6d57b77d7369ed73836c82b25f785b34923eef84; https://git.kernel.org/stable/c/d3affdeb400f3adc925bd996f3839481f5291839
CVE: CVE-2023-53058
Published: 2025-05-02
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: E-Switch, Fix an Oops in error handling code

The error handling dereferences "vport".  There is nothing we can do if
it is an error pointer except returning the error code.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/1a9853a7437a22fd849347008fb3c85087906b56; https://git.kernel.org/stable/c/388188fb58bef9e7f3ca4f8970f03d493b66909f; https://git.kernel.org/stable/c/5eadc80328298ef7beaaf0cd96791667d3b485ca
CVE: CVE-2023-53059
Published: 2025-05-02
Description: In the Linux kernel, the following vulnerability has been resolved:

platform/chrome: cros_ec_chardev: fix kernel data leak from ioctl

It is possible to peep kernel page's data by providing larger `insize`
in struct cros_ec_command[1] when invoking EC host commands.

Fix it by using zeroed memory.

[1]: https://elixir.bootlin.com/linux/v6.2/source/include/linux/platform_data/cros_ec_proto.h#L74
CVSS Score: 7.1 (HIGH)
References: https://git.kernel.org/stable/c/13493ad6a220cb3f6f3552a16b4f2753a118b633; https://git.kernel.org/stable/c/a0d8644784f73fa39f57f72f374eefaba2bf48a0; https://git.kernel.org/stable/c/b20cf3f89c56b5f6a38b7f76a8128bf9f291bbd3
CVE: CVE-2023-53060
Published: 2025-05-02
Description: In the Linux kernel, the following vulnerability has been resolved:

igb: revert rtnl_lock() that causes deadlock

The commit 6faee3d4ee8b ("igb: Add lock to avoid data race") adds
rtnl_lock to eliminate a false data race shown below

 (FREE from device detaching)      |   (USE from netdev core)
igb_remove                         |  igb_ndo_get_vf_config
 igb_disable_sriov                 |  vf >= adapter->vfs_allocated_count?
  kfree(adapter->vf_data)          |
  adapter->vfs_allocated_count = 0 |
                                   |    memcpy(... adapter->vf_data[vf]

The above race will never happen and the extra rtnl_lock causes deadlock
below

[  141.420169]  <TASK>
[  141.420672]  __schedule+0x2dd/0x840
[  141.421427]  schedule+0x50/0xc0
[  141.422041]  schedule_preempt_disabled+0x11/0x20
[  141.422678]  __mutex_lock.isra.13+0x431/0x6b0
[  141.423324]  unregister_netdev+0xe/0x20
[  141.423578]  igbvf_remove+0x45/0xe0 [igbvf]
[  141.423791]  pci_device_remove+0x36/0xb0
[  141.423990]  device_release_driver_internal+0xc1/0x160
[  141.424270]  pci_stop_bus_device+0x6d/0x90
[  141.424507]  pci_stop_and_remove_bus_device+0xe/0x20
[  141.424789]  pci_iov_remove_virtfn+0xba/0x120
[  141.425452]  sriov_disable+0x2f/0xf0
[  141.425679]  igb_disable_sriov+0x4e/0x100 [igb]
[  141.426353]  igb_remove+0xa0/0x130 [igb]
[  141.426599]  pci_device_remove+0x36/0xb0
[  141.426796]  device_release_driver_internal+0xc1/0x160
[  141.427060]  driver_detach+0x44/0x90
[  141.427253]  bus_remove_driver+0x55/0xe0
[  141.427477]  pci_unregister_driver+0x2a/0xa0
[  141.428296]  __x64_sys_delete_module+0x141/0x2b0
[  141.429126]  ? mntput_no_expire+0x4a/0x240
[  141.429363]  ? syscall_trace_enter.isra.19+0x126/0x1a0
[  141.429653]  do_syscall_64+0x5b/0x80
[  141.429847]  ? exit_to_user_mode_prepare+0x14d/0x1c0
[  141.430109]  ? syscall_exit_to_user_mode+0x12/0x30
[  141.430849]  ? do_syscall_64+0x67/0x80
[  141.431083]  ? syscall_exit_to_user_mode_prepare+0x183/0x1b0
[  141.431770]  ? syscall_exit_to_user_mode+0x12/0x30
[  141.432482]  ? do_syscall_64+0x67/0x80
[  141.432714]  ? exc_page_fault+0x64/0x140
[  141.432911]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

Since the igb_disable_sriov() will call pci_disable_sriov() before
releasing any resources, the netdev core will synchronize the cleanup to
avoid any races. This patch removes the useless rtnl_(un)lock to guarantee
correctness.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/0dabb72b923e17cb3b4ac99ea1adc9ef35116930; https://git.kernel.org/stable/c/4d2626e10709ff8474ffd1a9db3cf4647569e89c; https://git.kernel.org/stable/c/62a[PII_REDACTED]6f9d75af82a96440941f22b046f
CVE: CVE-2023-53061
Published: 2025-05-02
Description: In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix possible refcount leak in smb2_open()

Reference count of acls will leak when memory allocation fails. Fix this
by adding the missing posix_acl_release().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2624b445544ffc1472ccabfb6ec867c199d4c95c; https://git.kernel.org/stable/c/303f8e58cc3ace744801dcdcabfc06ffc72ed62d; https://git.kernel.org/stable/c/a22c49a05e5e7aa2c414fbc42c49c4c01a5c9a78
CVE: CVE-2023-53062
Published: 2025-05-02
Description: In the Linux kernel, the following vulnerability has been resolved:

net: usb: smsc95xx: Limit packet length to skb->len

Packet length retrieved from descriptor may be larger than
the actual socket buffer length. In such case the cloned
skb passed up the network stack will leak kernel memory contents.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/33d1603a38e05886c538129ddfe00bd52d347e7b; https://git.kernel.org/stable/c/70eb25c6a6cde149affe8a587371a3a8ad295ba0; https://git.kernel.org/stable/c/733580e268a53db1cd01f2251419da91866378f6
CVE: CVE-2023-53063
Published: 2025-05-02
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2023-53065
Published: 2025-05-02
Description: In the Linux kernel, the following vulnerability has been resolved:

perf/core: Fix perf_output_begin parameter is incorrectly invoked in perf_event_bpf_output

syzkaller reportes a KASAN issue with stack-out-of-bounds.
The call trace is as follows:
  dump_stack+0x9c/0xd3
  print_address_description.constprop.0+0x19/0x170
  __kasan_report.cold+0x6c/0x84
  kasan_report+0x3a/0x50
  __perf_event_header__init_id+0x34/0x290
  perf_event_header__init_id+0x48/0x60
  perf_output_begin+0x4a4/0x560
  perf_event_bpf_output+0x161/0x1e0
  perf_iterate_sb_cpu+0x29e/0x340
  perf_iterate_sb+0x4c/0xc0
  perf_event_bpf_event+0x194/0x2c0
  __bpf_prog_put.constprop.0+0x55/0xf0
  __cls_bpf_delete_prog+0xea/0x120 [cls_bpf]
  cls_bpf_delete_prog_work+0x1c/0x30 [cls_bpf]
  process_one_work+0x3c2/0x730
  worker_thread+0x93/0x650
  kthread+0x1b8/0x210
  ret_from_fork+0x1f/0x30

commit 267fb27352b6 ("perf: Reduce stack usage of perf_output_begin()")
use on-stack struct perf_sample_data of the caller function.

However, perf_event_bpf_output uses incorrect parameter to convert
small-sized data (struct perf_bpf_event) into large-sized data
(struct perf_sample_data), which causes memory overwriting occurs in
__perf_event_header__init_id.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/3a776fddb4e5598c8bfcd4ad094fba34f9856fc9; https://git.kernel.org/stable/c/ac5f88642cb211152041f84a985309e9af4baf59; https://git.kernel.org/stable/c/ddcf[PII_REDACTED]a06eb1e46412e045d0c5701575
CVE: CVE-2023-53066
Published: 2025-05-02
Description: In the Linux kernel, the following vulnerability has been resolved:

qed/qed_sriov: guard against NULL derefs from qed_iov_get_vf_info

We have to make sure that the info returned by the helper is valid
before using it.

Found by Linux Verification Center (linuxtesting.org) with the SVACE
static analysis tool.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/25143b6a01d0cc5319edd3de22ffa2578b045550; https://git.kernel.org/stable/c/39c3b9dd481c3afce9439b29bafe00444cb4406b; https://git.kernel.org/stable/c/42d72c6d1edc9dc09a5d6f6695d257fa9e9cc270
CVE: CVE-2023-53068
Published: 2025-05-02
Description: In the Linux kernel, the following vulnerability has been resolved:

net: usb: lan78xx: Limit packet length to skb->len

Packet length retrieved from descriptor may be larger than
the actual socket buffer length. In such case the cloned
skb passed up the network stack will leak kernel memory contents.

Additionally prevent integer underflow when size is less than
ETH_FCS_LEN.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/44b9ed73369fc5ec85dd2ee487e986301792a82d; https://git.kernel.org/stable/c/7f247f5a2c18b3f21206cdd51193df4f38e1b9f5; https://git.kernel.org/stable/c/83de34967473ed31d[PII_REDACTED]13cc2869a42e5
CVE: CVE-2023-53069
Published: 2025-05-02
Description: In the Linux kernel, the following vulnerability has been resolved:

octeontx2-vf: Add missing free for alloc_percpu

Add the free_percpu for the allocated "vf->hw.lmt_info" in order to avoid
memory leak, same as the "pf->hw.lmt_info" in
`drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c`.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/813b[PII_REDACTED]90c738ce6dbfd0c5938a1bafb9; https://git.kernel.org/stable/c/840631bcf21f58c0a3f01378a54d79e9ce86b226; https://git.kernel.org/stable/c/90874b76e5f82eaa3309714d72ff2cd8bb8d1b02
CVE: CVE-2023-53070
Published: 2025-05-02
Description: In the Linux kernel, the following vulnerability has been resolved:

ACPI: PPTT: Fix to avoid sleep in the atomic context when PPTT is absent

Commit 0c80f9e165f8 ("ACPI: PPTT: Leave the table mapped for the runtime usage")
enabled to map PPTT once on the first invocation of acpi_get_pptt() and
never unmapped the same allowing it to be used at runtime with out the
hassle of mapping and unmapping the table. This was needed to fetch LLC
information from the PPTT in the cpuhotplug path which is executed in
the atomic context as the acpi_get_table() might sleep waiting for a
mutex.

However it missed to handle the case when there is no PPTT on the system
which results in acpi_get_pptt() being called from all the secondary
CPUs attempting to fetch the LLC information in the atomic context
without knowing the absence of PPTT resulting in the splat like below:

 | BUG: sleeping function called from invalid context at kernel/locking/semaphore.c:164
 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1
 | preempt_count: 1, expected: 0
 | RCU nest depth: 0, expected: 0
 | no locks held by swapper/1/0.
 | irq event stamp: 0
 | hardirqs last  enabled at (0): 0x0
 | hardirqs last disabled at (0): copy_process+0x61c/0x1b40
 | softirqs last  enabled at (0): copy_process+0x61c/0x1b40
 | softirqs last disabled at (0): 0x0
 | CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.3.0-rc1 #1
 | Call trace:
 |  dump_backtrace+0xac/0x138
 |  show_stack+0x30/0x48
 |  dump_stack_lvl+0x60/0xb0
 |  dump_stack+0x18/0x28
 |  __might_resched+0x160/0x270
 |  __might_sleep+0x58/0xb0
 |  down_timeout+0x34/0x98
 |  acpi_os_wait_semaphore+0x7c/0xc0
 |  acpi_ut_acquire_mutex+0x58/0x108
 |  acpi_get_table+0x40/0xe8
 |  acpi_get_pptt+0x48/0xa0
 |  acpi_get_cache_info+0x38/0x140
 |  init_cache_level+0xf4/0x118
 |  detect_cache_attributes+0x2e4/0x640
 |  update_siblings_masks+0x3c/0x330
 |  store_cpu_topology+0x88/0xf0
 |  secondary_start_kernel+0xd0/0x168
 |  __secondary_switched+0xb8/0xc0

Update acpi_get_pptt() to consider the fact that PPTT is once checked and
is not available on the system and return NULL avoiding any attempts to
fetch PPTT and thereby avoiding any possible sleep waiting for a mutex
in the atomic context.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-252
References: https://git.kernel.org/stable/c/1318a07706bb2f8c65f88f39a16c2b5260bcdcd4; https://git.kernel.org/stable/c/91d7b60a65d9f71230ea09b86d2058a884a3c2af; https://git.kernel.org/stable/c/e0c1106d51b9abc8eae03c5522b20649b6a55f6e
CVE: CVE-2023-53071
Published: 2025-05-02
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: do not run mt76_unregister_device() on unregistered hw

Trying to probe a mt7921e pci card without firmware results in a
successful probe where ieee80211_register_hw hasn't been called. When
removing the driver, ieee802111_unregister_hw is called unconditionally
leading to a kernel NULL pointer dereference.
Fix the issue running mt76_unregister_device routine just for registered
hw.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2d34f27714c97a9786a30b3bb54944d6d8ed612f; https://git.kernel.org/stable/c/41130c32f3a18fcc930316da17f3a5f3bc326aa1; https://git.kernel.org/stable/c/dffe86df26aee01a5fc56a175b7a7f157961e370
CVE: CVE-2023-53072
Published: 2025-05-02
Description: In the Linux kernel, the following vulnerability has been resolved:

mptcp: use the workqueue to destroy unaccepted sockets

Christoph reported a UaF at token lookup time after having
refactored the passive socket initialization part:

  BUG: KASAN: use-after-free in __token_bucket_busy+0x253/0x260
  Read of size 4 at addr ffff88810698d5b0 by task syz-executor653/3198

  CPU: 1 PID: 3198 Comm: syz-executor653 Not tainted 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
  Call Trace:
   <TASK>
   dump_stack_lvl+0x6e/0x91
   print_report+0x16a/0x46f
   kasan_report+0xad/0x130
   __token_bucket_busy+0x253/0x260
   mptcp_token_new_connect+0x13d/0x490
   mptcp_connect+0x4ed/0x860
   __inet_stream_connect+0x80e/0xd90
   tcp_sendmsg_fastopen+0x3ce/0x710
   mptcp_sendmsg+0xff1/0x1a20
   inet_sendmsg+0x11d/0x140
   __sys_sendto+0x405/0x490
   __x64_sys_sendto+0xdc/0x1b0
   do_syscall_64+0x3b/0x90
   entry_SYSCALL_64_after_hwframe+0x72/0xdc

We need to properly clean-up all the paired MPTCP-level
resources and be sure to release the msk last, even when
the unaccepted subflow is destroyed by the TCP internals
via inet_child_forget().

We can re-use the existing MPTCP_WORK_CLOSE_SUBFLOW infra,
explicitly checking that for the critical scenario: the
closed subflow is the MPC one, the msk is not accepted and
eventually going through full cleanup.

With such change, __mptcp_destroy_sock() is always called
on msk sockets, even on accepted ones. We don't need anymore
to transiently drop one sk reference at msk clone time.

Please note this commit depends on the parent one:

  mptcp: refactor passive socket initialization
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/2827f099b3fb9a59263c997400e9182f5d423e84; https://git.kernel.org/stable/c/804cf487fb0031f3c74755b78d8663333f0ba636; https://git.kernel.org/stable/c/b6985b9b82954caa53f862d6059d06c0526254f0
CVE: CVE-2023-53073
Published: 2025-05-02
Description: In the Linux kernel, the following vulnerability has been resolved:

perf/x86/amd/core: Always clear status for idx

The variable 'status' (which contains the unhandled overflow bits) is
not being properly masked in some cases, displaying the following
warning:

  WARNING: CPU: 156 PID: 475601 at arch/x86/events/amd/core.c:972 amd_pmu_v2_handle_irq+0x216/0x270

This seems to be happening because the loop is being continued before
the status bit being unset, in case x86_perf_event_set_period()
returns 0. This is also causing an inconsistency because the "handled"
counter is incremented, but the status bit is not cleaned.

Move the bit cleaning together above, together when the "handled"
counter is incremented.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/263f5ecaf7080513efc248ec739b6d9e00f4129f; https://git.kernel.org/stable/c/9d4c7b1f12e101d6d[PII_REDACTED]b127416ddfb6c; https://git.kernel.org/stable/c/ab33a8f7649b0324639a336e1081aaea51a4523e