deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2023-53166
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

power: supply: bq25890: Fix external_power_changed race

bq25890_charger_external_power_changed() dereferences bq->charger,
which gets sets in bq25890_power_supply_init() like this:

  bq->charger = devm_power_supply_register(bq->dev, &bq->desc, &psy_cfg);

As soon as devm_power_supply_register() has called device_add()
the external_power_changed callback can get called. So there is a window
where bq25890_charger_external_power_changed() may get called while
bq->charger has not been set yet leading to a NULL pointer dereference.

This race hits during boot sometimes on a Lenovo Yoga Book 1 yb1-x90f
when the cht_wcove_pwrsrc (extcon) power_supply is done with detecting
the connected charger-type which happens to exactly hit the small window:

  BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
  <snip>
  RIP: 0010:__power_supply_is_supplied_by+0xb/0xb0
  <snip>
  Call Trace:
   <TASK>
   __power_supply_get_supplier_property+0x19/0x50
   class_for_each_device+0xb1/0xe0
   power_supply_get_property_from_supplier+0x2e/0x50
   bq25890_charger_external_power_changed+0x38/0x1b0 [bq25890_charger]
   __power_supply_changed_work+0x30/0x40
   class_for_each_device+0xb1/0xe0
   power_supply_changed_work+0x5f/0xe0
  <snip>

Fixing this is easy. The external_power_changed callback gets passed
the power_supply which will eventually get stored in bq->charger,
so bq25890_charger_external_power_changed() can simply directly use
the passed in psy argument which is always valid.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/029a443b9b6424170f00f6dd5b7682e682cce92e; https://git.kernel.org/stable/c/72c28207c19c2c46fab8ae994aff25e197fb2949; https://git.kernel.org/stable/c/9d20fa1982c35697f3f8c4ae0f12791691ae5958
CVE: CVE-2023-53167
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

tracing: Fix null pointer dereference in tracing_err_log_open()

Fix an issue in function 'tracing_err_log_open'.
The function doesn't call 'seq_open' if the file is opened only with
write permissions, which results in 'file->private_data' being left as null.
If we then use 'lseek' on that opened file, 'seq_lseek' dereferences
'file->private_data' in 'mutex_lock(&m->lock)', resulting in a kernel panic.
Writing to this node requires root privileges, therefore this bug
has very little security impact.

Tracefs node: /sys/kernel/tracing/error_log

Example Kernel panic:

Unable to handle kernel NULL pointer dereference at virtual address [PII_REDACTED]
Call trace:
 mutex_lock+0x30/0x110
 seq_lseek+0x34/0xb8
 __arm64_sys_lseek+0x6c/0xb8
 invoke_syscall+0x58/0x13c
 el0_svc_common+0xc4/0x10c
 do_el0_svc+0x24/0x98
 el0_svc+0x24/0x88
 el0t_64_sync_handler+0x84/0xe4
 el0t_64_sync+0x1b4/0x1b8
Code: d503201f aa0803e0 aa1f03e1 aa0103e9 (c8e97d02)
---[ end trace 561d1b49c12cf8a5 ]---
Kernel panic - not syncing: Oops: Fatal exception
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/02b0095e2fbbc060560c1065f86a211d91e27b26; https://git.kernel.org/stable/c/1e1c9aa9288a46c342f0f2c5c0b1c0876b9b0276; https://git.kernel.org/stable/c/3b5d9b7b875968a8a8c99dac45cb85b705c44802
CVE: CVE-2023-53168
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: ucsi_acpi: Increase the command completion timeout

Commit 130a96d698d7 ("usb: typec: ucsi: acpi: Increase command
completion timeout value") increased the timeout from 5 seconds
to 60 seconds due to issues related to alternate mode discovery.

After the alternate mode discovery switch to polled mode
the timeout was reduced, but instead of being set back to
5 seconds it was reduced to 1 second.

This is causing problems when using a Lenovo ThinkPad X1 yoga gen7
connected over Type-C to a LG 27UL850-W (charging DP over Type-C).

When the monitor is already connected at boot the following error
is logged: "PPM init failed (-110)", /sys/class/typec is empty and
on unplugging the NULL pointer deref fixed earlier in this series
happens.

When the monitor is connected after boot the following error
is logged instead: "GET_CONNECTOR_STATUS failed (-110)".

Setting the timeout back to 5 seconds fixes both cases.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/02d210f434249a7edbc160969b75df030dc6934d; https://git.kernel.org/stable/c/1e8525f37871741a[PII_REDACTED]3962f8bdcab15a; https://git.kernel.org/stable/c/8346d21d1d8a63f46f60e6899f4f80b1306acf32
CVE: CVE-2023-53169
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/resctrl: Clear staged_config[] before and after it is used

As a temporary storage, staged_config[] in rdt_domain should be cleared
before and after it is used. The stale value in staged_config[] could
cause an MSR access error.

Here is a reproducer on a system with 16 usable CLOSIDs for a 15-way L3
Cache (MBA should be disabled if the number of CLOSIDs for MB is less than
16.) :
	mount -t resctrl resctrl -o cdp /sys/fs/resctrl
	mkdir /sys/fs/resctrl/p{1..7}
	umount /sys/fs/resctrl/
	mount -t resctrl resctrl /sys/fs/resctrl
	mkdir /sys/fs/resctrl/p{1..8}

An error occurs when creating resource group named p8:
    unchecked MSR access error: WRMSR to 0xca0 (tried to write 0x[PII_REDACTED]0007ff) at rIP: 0xffffffff82249142 (cat_wrmsr+0x32/0x60)
    Call Trace:
     <IRQ>
     __flush_smp_call_function_queue+0x11d/0x170
     __sysvec_call_function+0x24/0xd0
     sysvec_call_function+0x89/0xc0
     </IRQ>
     <TASK>
     asm_sysvec_call_function+0x16/0x20

When creating a new resource control group, hardware will be configured
by the following process:
    rdtgroup_mkdir()
      rdtgroup_mkdir_ctrl_mon()
        rdtgroup_init_alloc()
          resctrl_arch_update_domains()

resctrl_arch_update_domains() iterates and updates all resctrl_conf_type
whose have_new_ctrl is true. Since staged_config[] holds the same values as
when CDP was enabled, it will continue to update the CDP_CODE and CDP_DATA
configurations. When group p8 is created, get_config_index() called in
resctrl_arch_update_domains() will return 16 and 17 as the CLOSIDs for
CDP_CODE and CDP_DATA, which will be translated to an invalid register -
0xca0 in this scenario.

Fix it by clearing staged_config[] before and after it is used.

[reinette: re-order commit tags]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0424a7dfe9129b93f29b277511a60e87f052ac6b; https://git.kernel.org/stable/c/3fc5941ecc31a495b6b84b465f36155009db99b5; https://git.kernel.org/stable/c/86db319d25db70cf4af4557e05f6fa6f39c70003
CVE: CVE-2023-53170
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

net: dsa: Removed unneeded of_node_put in felix_parse_ports_node

Remove unnecessary of_node_put from the continue path to prevent
child node from being released twice, which could avoid resource
leak or other unexpected issues.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/04499f28b40bfc24f20b0e2331008bb90a54a6cf; https://git.kernel.org/stable/c/7ead10b44b79ce8bfcd51e749d54e009de5f511a
CVE: CVE-2023-53171
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

vfio/type1: prevent underflow of locked_vm via exec()

When a vfio container is preserved across exec, the task does not change,
but it gets a new mm with locked_vm=0, and loses the count from existing
dma mappings.  If the user later unmaps a dma mapping, locked_vm underflows
to a large unsigned value, and a subsequent dma map request fails with
ENOMEM in __account_locked_vm.

To avoid underflow, grab and save the mm at the time a dma is mapped.
Use that mm when adjusting locked_vm, rather than re-acquiring the saved
task's mm, which may have changed.  If the saved mm is dead, do nothing.

locked_vm is incremented for existing mappings in a subsequent patch.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/046eca5018f8a5dd1dc2cedf87fb5843b9ea3026; https://git.kernel.org/stable/c/5a[PII_REDACTED]46cc016736fb76be2b40ee49b0c3; https://git.kernel.org/stable/c/a6b2aabe664098d5cf877ae0fd96459464a30e17
CVE: CVE-2023-53172
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

fsverity: reject FS_IOC_ENABLE_VERITY on mode 3 fds

Commit 56124d6c87fd ("fsverity: support enabling with tree block size <
PAGE_SIZE") changed FS_IOC_ENABLE_VERITY to use __kernel_read() to read
the file's data, instead of direct pagecache accesses.

An unintended consequence of this is that the
'WARN_ON_ONCE(!(file->f_mode & FMODE_READ))' in __kernel_read() became
reachable by fuzz tests.  This happens if FS_IOC_ENABLE_VERITY is called
on a fd opened with access mode 3, which means "ioctl access only".

Arguably, FS_IOC_ENABLE_VERITY should work on ioctl-only fds.  But
ioctl-only fds are a weird Linux extension that is rarely used and that
few people even know about.  (The documentation for FS_IOC_ENABLE_VERITY
even specifically says it requires O_RDONLY.)  It's probably not
worthwhile to make the ioctl internally open a new fd just to handle
this case.  Thus, just reject the ioctl on such fds for now.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/[PII_REDACTED]3cf60d4c5fc792214a08830e294ff8; https://git.kernel.org/stable/c/85c039cff3c359967cafe90443c02321e950b216
CVE: CVE-2023-53173
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

tty: pcn_uart: fix memory leak with using debugfs_lookup()

When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time.  To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic
at once.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/04a189c720aa2b[PII_REDACTED]ce9b9bc93552dff8; https://git.kernel.org/stable/c/139769c4bd8273b5e3f85ea474aa37018fe7e436; https://git.kernel.org/stable/c/4459d1e7bd0421b3b6fcd745773d8823f71615ef
CVE: CVE-2023-53174
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: core: Fix possible memory leak if device_add() fails

If device_add() returns error, the name allocated by dev_set_name() needs
be freed. As the comment of device_add() says, put_device() should be used
to decrease the reference count in the error path. So fix this by calling
put_device(), then the name can be freed in kobject_cleanp().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/04b5b5cb0136ce970333a9c6cec7e46adba1ea3a; https://git.kernel.org/stable/c/06c[PII_REDACTED]aa1195aec43a776e3185fbf7f56; https://git.kernel.org/stable/c/43c0e16d0c5ec59398b405f4c4aa5a076e656c3f
CVE: CVE-2023-53175
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

PCI: hv: Fix a crash in hv_pci_restore_msi_msg() during hibernation

When a Linux VM with an assigned PCI device runs on Hyper-V, if the PCI
device driver is not loaded yet (i.e. MSI-X/MSI is not enabled on the
device yet), doing a VM hibernation triggers a panic in
hv_pci_restore_msi_msg() -> msi_lock_descs(&pdev->dev), because
pdev->dev.msi.data is still NULL.

Avoid the panic by checking if MSI-X/MSI is enabled.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/04bbe863241a9be7d57fb4cf217ee4a72f480e70; https://git.kernel.org/stable/c/223fc[PII_REDACTED]f70b8b5e10cfc2f297e70c512; https://git.kernel.org/stable/c/d[PII_REDACTED]b21d252b98dca6be459153a60c62a
CVE: CVE-2023-53176
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

serial: 8250: Reinit port->pm on port specific driver unbind

When we unbind a serial port hardware specific 8250 driver, the generic
serial8250 driver takes over the port. After that we see an oops about 10
seconds later. This can produce the following at least on some TI SoCs:

Unhandled fault: imprecise external abort (0x1406)
Internal error: : 1406 [#1] SMP ARM

Turns out that we may still have the serial port hardware specific driver
port->pm in use, and serial8250_pm() tries to call it after the port
specific driver is gone:

serial8250_pm [8250_base] from uart_change_pm+0x54/0x8c [serial_base]
uart_change_pm [serial_base] from uart_hangup+0x154/0x198 [serial_base]
uart_hangup [serial_base] from __tty_hangup.part.0+0x328/0x37c
__tty_hangup.part.0 from disassociate_ctty+0x154/0x20c
disassociate_ctty from do_exit+0x744/0xaac
do_exit from do_group_exit+0x40/0x8c
do_group_exit from __wake_up_parent+0x0/0x1c

Let's fix the issue by calling serial8250_set_defaults() in
serial8250_unregister_port(). This will set the port back to using
the serial8250 default functions, and sets the port->pm to point to
serial8250_pm.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/04e82793f068d2f0ffe62fcea03d007a8cdc16a7; https://git.kernel.org/stable/c/1ba5594739d858e524ff0f398ee1ebfe0a8b9d41; https://git.kernel.org/stable/c/2c86a1305c1406f45ea780d06953c484ea1d9e6e
CVE: CVE-2023-53177
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

media: hi846: fix usage of pm_runtime_get_if_in_use()

pm_runtime_get_if_in_use() does not only return nonzero values when
the device is in use, it can return a negative errno too.

And especially during resuming from system suspend, when runtime pm
is not yet up again, -EAGAIN is being returned, so the subsequent
pm_runtime_put() call results in a refcount underflow.

Fix system-resume by handling -EAGAIN of pm_runtime_get_if_in_use().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/04fc06f6dc1592ed5d675311ac50d8fba5db62ab; https://git.kernel.org/stable/c/42ec6269f98edd915ee37da3c6456bb6243ea56a; https://git.kernel.org/stable/c/c5dcd7a19f1ed8fe98384f3a9444c7c53befd74e
CVE: CVE-2023-53178
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

mm: fix zswap writeback race condition

The zswap writeback mechanism can cause a race condition resulting in
memory corruption, where a swapped out page gets swapped in with data that
was written to a different page.

The race unfolds like this:
1. a page with data A and swap offset X is stored in zswap
2. page A is removed off the LRU by zpool driver for writeback in
   zswap-shrink work, data for A is mapped by zpool driver
3. user space program faults and invalidates page entry A, offset X is
   considered free
4. kswapd stores page B at offset X in zswap (zswap could also be
   full, if so, page B would then be IOed to X, then skip step 5.)
5. entry A is replaced by B in tree->rbroot, this doesn't affect the
   local reference held by zswap-shrink work
6. zswap-shrink work writes back A at X, and frees zswap entry A
7. swapin of slot X brings A in memory instead of B

The fix:
Once the swap page cache has been allocated (case ZSWAP_SWAPCACHE_NEW),
zswap-shrink work just checks that the local zswap_entry reference is
still the same as the one in the tree.  If it's not the same it means that
it's either been invalidated or replaced, in both cases the writeback is
aborted because the local entry contains stale data.

Reproducer:
I originally found this by running `stress` overnight to validate my work
on the zswap writeback mechanism, it manifested after hours on my test
machine.  The key to make it happen is having zswap writebacks, so
whatever setup pumps /sys/kernel/debug/zswap/written_back_pages should do
the trick.

In order to reproduce this faster on a vm, I setup a system with ~100M of
available memory and a 500M swap file, then running `stress --vm 1
--vm-bytes 300000000 --vm-stride 4000` makes it happen in matter of tens
of minutes.  One can speed things up even more by swinging
/sys/module/zswap/parameters/max_pool_percent up and down between, say, 20
and 1; this makes it reproduce in tens of seconds.  It's crucial to set
`--vm-stride` to something other than 4096 otherwise `stress` won't
realize that memory has been corrupted because all pages would have the
same data.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/04fc7816089c5a32c29a04ec94b998e219dfb946; https://git.kernel.org/stable/c/2cab13f500a6333bd2b853783ac76be9e4956f8a; https://git.kernel.org/stable/c/ba700ea13bf0105a4773c654f7d3bef8adb64ab2
CVE: CVE-2023-53179
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: ipset: add the missing IP_SET_HASH_WITH_NET0 macro for ip_set_hash_netportnet.c

The missing IP_SET_HASH_WITH_NET0 macro in ip_set_hash_netportnet can
lead to the use of wrong `CIDR_POS(c)` for calculating array offsets,
which can lead to integer underflow. As a result, it leads to slab
out-of-bound access.
This patch adds back the IP_SET_HASH_WITH_NET0 macro to
ip_set_hash_netportnet to address the issue.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/050d91c03b28ca479df13dfb02bcd2c60dd6a878; https://git.kernel.org/stable/c/109e830585e89a03d554bf8ad0e668630d0a6260; https://git.kernel.org/stable/c/7935b636dd693dfe4483cfef4a1e91366c8103fa
CVE: CVE-2023-53180
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: Avoid NULL pointer access during management transmit cleanup

Currently 'ar' reference is not added in skb_cb.
Though this is generally not used during transmit completion
callbacks, on interface removal the remaining idr cleanup callback
uses the ar pointer from skb_cb from management txmgmt_idr. Hence fill them
during transmit call for proper usage to avoid NULL pointer dereference.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/054b5580a36e435692c203c19abdcb9f7734320e; https://git.kernel.org/stable/c/7382d02160ef93c806fe1c1d4ef1fec445266747
CVE: CVE-2023-53181
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

dma-buf/dma-resv: Stop leaking on krealloc() failure

Currently dma_resv_get_fences() will leak the previously
allocated array if the fence iteration got restarted and
the krealloc_array() fails.

Free the old array by hand, and make sure we still clear
the returned *fences so the caller won't end up accessing
freed memory. Some (but not all) of the callers of
dma_resv_get_fences() seem to still trawl through the
array even when dma_resv_get_fences() failed. And let's
zero out *num_fences as well for good measure.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/05abb3be91d[PII_REDACTED]ee02973ab3d47f5e3d2; https://git.kernel.org/stable/c/19e7b9f1f7e1cb92a4cc53b4c064f7fb4b1f1983; https://git.kernel.org/stable/c/819656cc03dec7f7f7800274dfbc8eb49f888e9f
CVE: CVE-2023-53183
Published: 2025-09-15
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2023-53184
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

arm64/sme: Set new vector length before reallocating

As part of fixing the allocation of the buffer for SVE state when changing
SME vector length we introduced an immediate reallocation of the SVE state,
this is also done when changing the SVE vector length for consistency.
Unfortunately this reallocation is done prior to writing the new vector
length to the task struct, meaning the allocation is done with the old
vector length and can lead to memory corruption due to an undersized buffer
being used.

Move the update of the vector length before the allocation to ensure that
the new vector length is taken into account.

For some reason this isn't triggering any problems when running tests on
the arm64 fixes branch (even after repeated tries) but is triggering
issues very often after merge into mainline.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/05d881b85b48c7ac6a7c92ce00aa916c4a84d052; https://git.kernel.org/stable/c/356e711640aea6ed145da[PII_REDACTED]b45264cb4; https://git.kernel.org/stable/c/807ada0e4aa3c9090c66009a99fa530c462012c9
CVE: CVE-2023-53185
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath9k: don't allow to overwrite ENDPOINT0 attributes

A bad USB device is able to construct a service connection response
message with target endpoint being ENDPOINT0 which is reserved for
HTC_CTRL_RSVD_SVC and should not be modified to be used for any other
services.

Reject such service connection responses.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/061b0cb9327b80d7a0f63a33e7c3e2a91a71f142; https://git.kernel.org/stable/c/09740fa9827cfbaf23ecd041e602a426f99be888; https://git.kernel.org/stable/c/1044187e7249073f719ebbf9e5ffb4f16f99e555
CVE: CVE-2023-53186
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

skbuff: Fix a race between coalescing and releasing SKBs

Commit 1effe8ca4e34 ("skbuff: fix coalescing for page_pool fragment
recycling") allowed coalescing to proceed with non page pool page and page
pool page when @from is cloned, i.e.

to->pp_recycle    --> false
from->pp_recycle  --> true
skb_cloned(from)  --> true

However, it actually requires skb_cloned(@from) to hold true until
coalescing finishes in this situation. If the other cloned SKB is
released while the merging is in process, from_shinfo->nr_frags will be
set to 0 toward the end of the function, causing the increment of frag
page _refcount to be unexpectedly skipped resulting in inconsistent
reference counts. Later when SKB(@to) is released, it frees the page
directly even though the page pool page is still in use, leading to
use-after-free or double-free errors. So it should be prohibited.

The double-free error message below prompted us to investigate:
BUG: Bad page state in process swapper/1  pfn:0e0d1
page:00000000c6548b28 refcount:-1 mapcount:0 mapping:[PII_REDACTED]
index:0x2 pfn:0xe0d1
flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)
raw: 000fffffc0000000 [PII_REDACTED] ffffffff00000101 [PII_REDACTED]
raw: [PII_REDACTED] [PII_REDACTED] ffffffffffffffff [PII_REDACTED]
page dumped because: nonzero _refcount

CPU: 1 PID: 0 Comm: swapper/1 Tainted: G            E      6.2.0+
Call Trace:
 <IRQ>
dump_stack_lvl+0x32/0x50
bad_page+0x69/0xf0
free_pcp_prepare+0x260/0x2f0
free_unref_page+0x20/0x1c0
skb_release_data+0x10b/0x1a0
napi_consume_skb+0x56/0x150
net_rx_action+0xf0/0x350
? __napi_schedule+0x79/0x90
__do_softirq+0xc8/0x2b1
__irq_exit_rcu+0xb9/0xf0
common_interrupt+0x82/0xa0
</IRQ>
<TASK>
asm_common_interrupt+0x22/0x40
RIP: 0010:default_idle+0xb/0x20
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/0646dc31ca886693274df5749cd0c8c1eaaeb5ca; https://git.kernel.org/stable/c/5f692c992a3bb9a8018e3488098b401a4229e7ec; https://git.kernel.org/stable/c/71850b5af92da21b4862a9bc55bda61091247d00