deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2023-53636
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: microchip: fix potential UAF in auxdev release callback

Similar to commit 1c11289b34ab ("peci: cpu: Fix use-after-free in
adev_release()"), the auxiliary device is not torn down in the correct
order. If auxiliary_device_add() fails, the release callback will be
called twice, resulting in a UAF. Due to timing, the auxdev code in this
driver "took inspiration" from the aforementioned commit, and thus its
bugs too!

Moving auxiliary_device_uninit() to the unregister callback instead
avoids the issue.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/5b4052aa956e11bcd19e50ca559eb38dcb46201b; https://git.kernel.org/stable/c/7455b7007b9e93bcc2bc9c1c6c73a228e3152069; https://git.kernel.org/stable/c/934406b2d42eaf3fc57f5546cc68ff7ab9680bb3
CVE: CVE-2023-53637
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

media: i2c: ov772x: Fix memleak in ov772x_probe()

A memory leak was reported when testing ov772x with bpf mock device:

AssertionError: unreferenced object 0xffff888109afa7a8 (size 8):
  comm "python3", pid 279, jiffies[PII_REDACTED] (age 20.681s)
  hex dump (first 8 bytes):
    80 22 88 15 81 88 ff ff                          ."......
  backtrace:
    [<[PII_REDACTED]90b438>] __kmalloc_node+0x44/0x1b0
    [<000000009e32f7d7>] kvmalloc_node+0x34/0x180
    [<00000000faf48134>] v4l2_ctrl_handler_init_class+0x11d/0x180 [videodev]
    [<00000000da376937>] ov772x_probe+0x1c3/0x68c [ov772x]
    [<000000003f0d225e>] i2c_device_probe+0x28d/0x680
    [<00000000e0b6db89>] really_probe+0x17c/0x3f0
    [<000000001b19fcee>] __driver_probe_device+0xe3/0x170
    [<[PII_REDACTED]>] driver_probe_device+0x49/0x120
    [<000000005ead07a0>] __device_attach_driver+0xf7/0x150
    [<[PII_REDACTED]f452b8>] bus_for_each_drv+0x114/0x180
    [<[PII_REDACTED]8e5596>] __device_attach+0x1e5/0x2d0
    [<[PII_REDACTED]f83c5d>] bus_probe_device+0x126/0x140
    [<00000000ee0f3046>] device_add+0x810/0x1130
    [<00000000e0278184>] i2c_new_client_device+0x359/0x4f0
    [<[PII_REDACTED]baf34f>] of_i2c_register_device+0xf1/0x110
    [<00000000a9f2159d>] of_i2c_notify+0x100/0x160
unreferenced object 0xffff888119825c00 (size 256):
  comm "python3", pid 279, jiffies[PII_REDACTED] (age 20.681s)
  hex dump (first 32 bytes):
    00 b4 a5 17 81 88 ff ff 00 5e 82 19 81 88 ff ff  .........^......
    10 5c 82 19 81 88 ff ff 10 5c 82 19 81 88 ff ff  .\.......\......
  backtrace:
    [<[PII_REDACTED]90b438>] __kmalloc_node+0x44/0x1b0
    [<000000009e32f7d7>] kvmalloc_node+0x34/0x180
    [<[PII_REDACTED]d88e0b>] v4l2_ctrl_new.cold+0x19b/0x86f [videodev]
    [<00000000b1f576fb>] v4l2_ctrl_new_std+0x16f/0x210 [videodev]
    [<00000000caf7ac99>] ov772x_probe+0x1fa/0x68c [ov772x]
    [<000000003f0d225e>] i2c_device_probe+0x28d/0x680
    [<00000000e0b6db89>] really_probe+0x17c/0x3f0
    [<000000001b19fcee>] __driver_probe_device+0xe3/0x170
    [<[PII_REDACTED]>] driver_probe_device+0x49/0x120
    [<000000005ead07a0>] __device_attach_driver+0xf7/0x150
    [<[PII_REDACTED]f452b8>] bus_for_each_drv+0x114/0x180
    [<[PII_REDACTED]8e5596>] __device_attach+0x1e5/0x2d0
    [<[PII_REDACTED]f83c5d>] bus_probe_device+0x126/0x140
    [<00000000ee0f3046>] device_add+0x810/0x1130
    [<00000000e0278184>] i2c_new_client_device+0x359/0x4f0
    [<[PII_REDACTED]baf34f>] of_i2c_register_device+0xf1/0x110

The reason is that if priv->hdl.error is set, ov772x_probe() jumps to the
error_mutex_destroy without doing v4l2_ctrl_handler_free(), and all
resources allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std()
are leaked.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/1da495101ef7507eb4f4b1dbec2874d740eff251; https://git.kernel.org/stable/c/448ce1cd50387b1345ec14eb191ef05f7afc2a26; https://git.kernel.org/stable/c/7485edb2b6ca5960205c0a49bedfd09bba30e521
CVE: CVE-2023-53638
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

octeon_ep: cancel queued works in probe error path

If it fails to get the devices's MAC address, octep_probe exits while
leaving the delayed work intr_poll_task queued. When the work later
runs, it's a use after free.

Move the cancelation of intr_poll_task from octep_remove into
octep_device_cleanup. This does not change anything in the octep_remove
flow, but octep_device_cleanup is called also in the octep_probe error
path, where the cancelation is needed.

Note that the cancelation of ctrl_mbox_task has to follow
intr_poll_task's, because the ctrl_mbox_task may be queued by
intr_poll_task.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/62312e2f6466b5f0a120542a38b410d88a34ed00; https://git.kernel.org/stable/c/758c91078165ae641b698750a72eafe7968b3756
CVE: CVE-2023-53639
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath6kl: reduce WARN to dev_dbg() in callback

The warn is triggered on a known race condition, documented in the code above
the test, that is correctly handled.  Using WARN() hinders automated testing.
Reducing severity.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0d1792c98351b7c8ebdc53d052918e77d1e512c3; https://git.kernel.org/stable/c/1300517e371e4d0acdb0f1237477e1ed223c3a9a; https://git.kernel.org/stable/c/484d95c69fc1143f09e4c2e3b89019d68d190a92
CVE: CVE-2023-53640
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: lpass: Fix for KASAN use_after_free out of bounds

When we run syzkaller we get below Out of Bounds error.

"KASAN: slab-out-of-bounds Read in regcache_flat_read"

Below is the backtrace of the issue:

BUG: KASAN: slab-out-of-bounds in regcache_flat_read+0x10c/0x110
Read of size 4 at addr ffffff8088fbf714 by task syz-executor.4/14144
CPU: 6 PID: 14144 Comm: syz-executor.4 Tainted: G        W
Hardware name: Qualcomm Technologies, Inc. sc7280 CRD platform (rev5+) (DT)
Call trace:
dump_backtrace+0x0/0x4ec
show_stack+0x34/0x50
dump_stack_lvl+0xdc/0x11c
print_address_description+0x30/0x2d8
kasan_report+0x178/0x1e4
__asan_report_load4_noabort+0x44/0x50
regcache_flat_read+0x10c/0x110
regcache_read+0xf8/0x5a0
_regmap_read+0x45c/0x86c
_regmap_update_bits+0x128/0x290
regmap_update_bits_base+0xc0/0x15c
snd_soc_component_update_bits+0xa8/0x22c
snd_soc_component_write_field+0x68/0xd4
tx_macro_put_dec_enum+0x1d0/0x268
snd_ctl_elem_write+0x288/0x474

By Error checking and checking valid values issue gets rectifies.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/75e5fab7db0cecb6e16b22c34608f0b40a4c7cd1; https://git.kernel.org/stable/c/8d81d3b0ed3610d24191d24f8e9e20f6775f0cc5; https://git.kernel.org/stable/c/8f1512d78b5de928f4616a871e77b58fd546e651
CVE: CVE-2023-53641
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath9k: hif_usb: fix memory leak of remain_skbs

hif_dev->remain_skb is allocated and used exclusively in
ath9k_hif_usb_rx_stream(). It is implied that an allocated remain_skb is
processed and subsequently freed (in error paths) only during the next
call of ath9k_hif_usb_rx_stream().

So, if the urbs are deallocated between those two calls due to the device
deinitialization or suspend, it is possible that ath9k_hif_usb_rx_stream()
is not called next time and the allocated remain_skb is leaked. Our local
Syzkaller instance was able to trigger that.

remain_skb makes sense when receiving two consecutive urbs which are
logically linked together, i.e. a specific data field from the first skb
indicates a cached skb to be allocated, memcpy'd with some data and
subsequently processed in the next call to ath9k_hif_usb_rx_stream(). Urbs
deallocation supposedly makes that link irrelevant so we need to free the
cached skb in those cases.

Fix the leak by introducing a function to explicitly free remain_skb (if
it is not NULL) when the rx urbs have been deallocated. remain_skb is NULL
when it has not been allocated at all (hif_dev struct is kzalloced) or
when it has been processed in next call to ath9k_hif_usb_rx_stream().

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/320d760a35273aa815d58b57e4fd9ba5279a3489; https://git.kernel.org/stable/c/59073060fe0950c6ecbe12bdc06469dcac62128d; https://git.kernel.org/stable/c/6719e3797ec52cd144c8a5ba8aaab[PII_REDACTED]5
CVE: CVE-2023-53643
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

nvme-tcp: don't access released socket during error recovery

While the error recovery work is temporarily failing reconnect attempts,
running the 'nvme list' command causes a kernel NULL pointer dereference
by calling getsockname() with a released socket.

During error recovery work, the nvme tcp socket is released and a new one
created, so it is not safe to access the socket without proper check.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/76d54bf20cdcc1ed7569a89885e09636e9a8d71d; https://git.kernel.org/stable/c/d82f762db4776fa11de88018f0f5de2d5db72a72; https://git.kernel.org/stable/c/fe2d9e54165dadaa0d0cc3355c0be9c3e129fa0d
CVE: CVE-2023-53644
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

media: radio-shark: Add endpoint checks

The syzbot fuzzer was able to provoke a WARNING from the radio-shark2
driver:

------------[ cut here ]------------
usb 1-1: BOGUS urb xfer, pipe 1 != type 3
WARNING: CPU: 0 PID: 3271 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed2/0x1880 drivers/usb/core/urb.c:504
Modules linked in:
CPU: 0 PID: 3271 Comm: kworker/0:3 Not tainted 6.1.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Workqueue: usb_hub_wq hub_event
RIP: 0010:usb_submit_urb+0xed2/0x1880 drivers/usb/core/urb.c:504
Code: 7c 24 18 e8 00 36 ea fb 48 8b 7c 24 18 e8 36 1c 02 ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 b6 90 8a e8 9a 29 b8 03 <0f> 0b e9 58 f8 ff ff e8 d2 35 ea fb 48 81 c5 c0 05 00 00 e9 84 f7
RSP: 0018:ffffc90003876dd0 EFLAGS: 00010282
RAX: [PII_REDACTED] RBX: [PII_REDACTED] RCX: [PII_REDACTED]
RDX: ffff8880750b0040 RSI: ffffffff816152b8 RDI: fffff5200070edac
RBP: ffff8880172d81e0 R08: [PII_REDACTED] R09: [PII_REDACTED]
R10: [PII_REDACTED] R11: [PII_REDACTED] R12: [PII_REDACTED]
R13: ffff8880285c5040 R14: [PII_REDACTED] R15: ffff[PII_REDACTED]00
FS:  [PII_REDACTED](0000) GS:ffff8880b9a00000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 00007ffe03235b90 CR3: 000000000bc8e000 CR4:[PII_REDACTED]3506f0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
Call Trace:
 <TASK>
 usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58
 usb_bulk_msg+0x226/0x550 drivers/usb/core/message.c:387
 shark_write_reg+0x1ff/0x2e0 drivers/media/radio/radio-shark2.c:88
...

The problem was caused by the fact that the driver does not check
whether the endpoints it uses are actually present and have the
appropriate types.  This can be fixed by adding a simple check of
these endpoints (and similarly for the radio-shark driver).
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2b580d0f03c4fc00013cd08f9ed96b87a08fd0d9; https://git.kernel.org/stable/c/3ed6a312ac1e7278f92b1b3d95377b335ae21e89; https://git.kernel.org/stable/c/4c3057a1927fa0b9ed8948b6f3b56b4ff9fa63d3
CVE: CVE-2023-53646
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/i915/perf: add sentinel to xehp_oa_b_counters

Arrays passed to reg_in_range_table should end with empty record.

The patch solves KASAN detected bug with signature:
BUG: KASAN: global-out-of-bounds in xehp_is_valid_b_counter_addr+0x2c7/0x350 [i915]
Read of size 4 at addr ffffffffa1555d90 by task perf/1518

CPU: 4 PID: 1518 Comm: perf Tainted: G U 6.4.0-kasan_438-g3303d06107f3+ #1
Hardware name: Intel Corporation Meteor Lake Client Platform/MTL-P DDR5 SODIMM SBS RVP, BIOS MTLPFWI1.R00.3223.D80[PII_REDACTED] 05/31/2023
Call Trace:
<TASK>
...
xehp_is_valid_b_counter_addr+0x2c7/0x350 [i915]

(cherry picked from commit 2f42c5afb34b5696cf5fe79e744f99be9b218798)
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/21d92025e80629fd5c25cd6751f8cf38c784dd4a; https://git.kernel.org/stable/c/785b3f667b4bf98804cad135005e964df0c750de
CVE: CVE-2023-53647
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

Drivers: hv: vmbus: Don't dereference ACPI root object handle

Since the commit referenced in the Fixes: tag below the VMBus client driver
is walking the ACPI namespace up from the VMBus ACPI device to the ACPI
namespace root object trying to find Hyper-V MMIO ranges.

However, if it is not able to find them it ends trying to walk resources of
the ACPI namespace root object itself.
This object has all-ones handle, which causes a NULL pointer dereference
in the ACPI code (from dereferencing this pointer with an offset).

This in turn causes an oops on boot with VMBus host implementations that do
not provide Hyper-V MMIO ranges in their VMBus ACPI device or its
ancestors.
The QEMU VMBus implementation is an example of such implementation.

I guess providing these ranges is optional, since all tested Windows
versions seem to be able to use VMBus devices without them.

Fix this by explicitly terminating the lookup at the ACPI namespace root
object.

Note that Linux guests under KVM/QEMU do not use the Hyper-V PV interface
by default - they only do so if the KVM PV interface is missing or
disabled.

Example stack trace of such oops:
[ 3.710827] ? __die+0x1f/0x60
[ 3.715030] ? page_fault_oops+0x159/0x460
[ 3.716008] ? exc_page_fault+0x73/0x170
[ 3.716959] ? asm_exc_page_fault+0x22/0x30
[ 3.717957] ? acpi_ns_lookup+0x7a/0x4b0
[ 3.718898] ? acpi_ns_internalize_name+0x79/0xc0
[ 3.720018] acpi_ns_get_node_unlocked+0xb5/0xe0
[ 3.721120] ? acpi_ns_check_object_type+0xfe/0x200
[ 3.722285] ? acpi_rs_convert_aml_to_resource+0x37/0x6e0
[ 3.723559] ? down_timeout+0x3a/0x60
[ 3.724455] ? acpi_ns_get_node+0x3a/0x60
[ 3.725412] acpi_ns_get_node+0x3a/0x60
[ 3.726335] acpi_ns_evaluate+0x1c3/0x2c0
[ 3.727295] acpi_ut_evaluate_object+0x64/0x1b0
[ 3.728400] acpi_rs_get_method_data+0x2b/0x70
[ 3.729476] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus]
[ 3.730940] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus]
[ 3.732411] acpi_walk_resources+0x78/0xd0
[ 3.733398] vmbus_platform_driver_probe+0x9f/0x1d0 [hv_vmbus]
[ 3.734802] platform_probe+0x3d/0x90
[ 3.735684] really_probe+0x19b/0x400
[ 3.736570] ? __device_attach_driver+0x100/0x100
[ 3.737697] __driver_probe_device+0x78/0x160
[ 3.738746] driver_probe_device+0x1f/0x90
[ 3.739743] __driver_attach+0xc2/0x1b0
[ 3.740671] bus_for_each_dev+0x70/0xc0
[ 3.741601] bus_add_driver+0x10e/0x210
[ 3.742527] driver_register+0x55/0xf0
[ 3.744412] ? 0xffffffffc039a000
[ 3.745207] hv_acpi_init+0x3c/0x1000 [hv_vmbus]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/64f09d45e94547fbf219f36d1d02ac42742c028c; https://git.kernel.org/stable/c/78e04bbff849b51b56f5925b1945db2c6e128b61; https://git.kernel.org/stable/c/96db43aced395844a7abc9a0a5cc702513e3534a
CVE: CVE-2023-53648
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: ac97: Fix possible NULL dereference in snd_ac97_mixer

smatch error:
sound/pci/ac97/ac97_codec.c:2354 snd_ac97_mixer() error:
we previously assumed 'rac97' could be null (see line 2072)

remove redundant assignment, return error if rac97 is NULL.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/09baf460dfba79ee6a0c72e68ccdbbba84d894df; https://git.kernel.org/stable/c/228da1fa124470606ac19783e551f9d51a1e01b0; https://git.kernel.org/stable/c/300e26e3e64880de5013eac8831cf44387ef752c
CVE: CVE-2023-53650
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

fbdev: omapfb: lcd_mipid: Fix an error handling path in mipid_spi_probe()

If 'mipid_detect()' fails, we must free 'md' to avoid a memory leak.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/09ea1ae4a2ec17774892cfcff50f6d33dfa1e06f; https://git.kernel.org/stable/c/3b4c21804076e461a6453ee4d[PII_REDACTED]6aa1d; https://git.kernel.org/stable/c/716efd08985e3104031d1b655930b1f1c45fa8a7
CVE: CVE-2023-53651
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

Input: exc3000 - properly stop timer on shutdown

We need to stop the timer on driver unbind or probe failures, otherwise
we get UAF/Oops.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/526a177ac6353d65057eadb5d6edafc168f64484; https://git.kernel.org/stable/c/79c81d137d36f9635bbcbc3916c0cccb418a61dd; https://git.kernel.org/stable/c/bee57c20fc0ca5ef9b9a53a0335eab2ac9e9cae1
CVE: CVE-2023-53652
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

vdpa: Add features attr to vdpa_nl_policy for nlattr length check

The vdpa_nl_policy structure is used to validate the nlattr when parsing
the incoming nlmsg. It will ensure the attribute being described produces
a valid nlattr pointer in info->attrs before entering into each handler
in vdpa_nl_ops.

That is to say, the missing part in vdpa_nl_policy may lead to illegal
nlattr after parsing, which could lead to OOB read just like CVE-2023-3773.

This patch adds the missing nla_policy for vdpa features attr to avoid
such bugs.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/44b508cc96889e61799cc0fc6c00766a54f3ab5a; https://git.kernel.org/stable/c/645d17e06c502e71b880b2b854930e5a64014640; https://git.kernel.org/stable/c/79c[PII_REDACTED]ba263d2fd67fd4406240fb21f69
CVE: CVE-2023-53653
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

media: amphion: fix REVERSE_INULL issues reported by coverity

null-checking of a pointor is suggested before dereferencing it
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/79d3bafaecc13bccab1ebbd28a15e669c5a4cdaf; https://git.kernel.org/stable/c/bddd678fd2864b435d00d51a4d3808a0d89c79de; https://git.kernel.org/stable/c/e59d0cd8f414592187ead97b5832600ff7a0dd61
CVE: CVE-2023-53654
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

octeontx2-af: Add validation before accessing cgx and lmac

with the addition of new MAC blocks like CN10K RPM and CN10KB
RPM_USX, LMACs are noncontiguous and CGX blocks are also
noncontiguous. But during RVU driver initialization, the driver
is assuming they are contiguous and trying to access
cgx or lmac with their id which is resulting in kernel panic.

This patch fixes the issue by adding proper checks.

[   23.219150] pc : cgx_lmac_read+0x38/0x70
[   23.219154] lr : rvu_program_channels+0x3f0/0x498
[   23.223852] sp : ffff000100d6fc80
[   23.227158] x29: ffff000100d6fc80 x28: ffff00010009f880 x27:[PII_REDACTED]00005a
[   23.234288] x26: ffff[PII_REDACTED]68 x25: [PII_REDACTED] x24:
fffffffffff0f000
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/79ebb53772c95d3a6ae51b3c65f9985fdd430df6; https://git.kernel.org/stable/c/a5485a943193e55c79150382e6461e8ea759e96e; https://git.kernel.org/stable/c/b04872e15f3df62cb2fd530950f769626e1ef489
CVE: CVE-2023-53656
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

drivers/perf: hisi: Don't migrate perf to the CPU going to teardown

The driver needs to migrate the perf context if the current using CPU going
to teardown. By the time calling the cpuhp::teardown() callback the
cpu_online_mask() hasn't updated yet and still includes the CPU going to
teardown. In current driver's implementation we may migrate the context
to the teardown CPU and leads to the below calltrace:

...
[  368.104662][  T932] task:cpuhp/0         state:D stack:    0 pid:   15 ppid:     2 flags:0x00000008
[  368.113699][  T932] Call trace:
[  368.116834][  T932]  __switch_to+0x7c/0xbc
[  368.120924][  T932]  __schedule+0x338/0x6f0
[  368.125098][  T932]  schedule+0x50/0xe0
[  368.128926][  T932]  schedule_preempt_disabled+0x18/0x24
[  368.134229][  T932]  __mutex_lock.constprop.0+0x1d4/0x5dc
[  368.139617][  T932]  __mutex_lock_slowpath+0x1c/0x30
[  368.144573][  T932]  mutex_lock+0x50/0x60
[  368.148579][  T932]  perf_pmu_migrate_context+0x84/0x2b0
[  368.153884][  T932]  hisi_pcie_pmu_offline_cpu+0x90/0xe0 [hisi_pcie_pmu]
[  368.160579][  T932]  cpuhp_invoke_callback+0x2a0/0x650
[  368.165707][  T932]  cpuhp_thread_fun+0xe4/0x190
[  368.170316][  T932]  smpboot_thread_fn+0x15c/0x1a0
[  368.175099][  T932]  kthread+0x108/0x13c
[  368.179012][  T932]  ret_from_fork+0x10/0x18
...

Use function cpumask_any_but() to find one correct active cpu to fixes
this issue.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/7a6a9f1c5a0a875a421db798d4b2ee022dc1ee1a; https://git.kernel.org/stable/c/b64569897d86b611befbb895d815280fea94e1ed; https://git.kernel.org/stable/c/be9c8c9c84b6d25a7b7d39954030aba6f759feb6
CVE: CVE-2023-53657
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

ice: Don't tx before switchdev is fully configured

There is possibility that ice_eswitch_port_start_xmit might be
called while some resources are still not allocated which might
cause NULL pointer dereference. Fix this by checking if switchdev
configuration was finished.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/5760a72b3060150b587eff3e879648c7470efddd; https://git.kernel.org/stable/c/63ff5a94649837d980e3b9ef535c793ec8cb0ca7; https://git.kernel.org/stable/c/7aa529a69e92b9aff585e569d5003f7c15d8d60b
CVE: CVE-2023-53658
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

spi: bcm-qspi: return error if neither hif_mspi nor mspi is available

If neither a "hif_mspi" nor "mspi" resource is present, the driver will
just early exit in probe but still return success. Apart from not doing
anything meaningful, this would then also lead to a null pointer access
on removal, as platform_get_drvdata() would return NULL, which it would
then try to dereference when trying to unregister the spi master.

Fix this by unconditionally calling devm_ioremap_resource(), as it can
handle a NULL res and will then return a viable ERR_PTR() if we get one.

The "return 0;" was previously a "goto qspi_resource_err;" where then
ret was returned, but since ret was still initialized to 0 at this place
this was a valid conversion in 63c5395bb7a9 ("spi: bcm-qspi: Fix
use-after-free on unbind"). The issue was not introduced by this commit,
only made more obvious.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/217b6ea8cf7b819477bca597a6ae2d43d38ba283; https://git.kernel.org/stable/c/22ae32d80ef590d12a2364e4621f90f7c58445c7; https://git.kernel.org/stable/c/32b9c8f7892c19f7f5c9fed5fb410b9fd5990bb6