bobroberts2639/cve-kev-snapshot-90d-2025-10-29 huggingface dataset:
CVE-2025-52855 (published 2025-10-03 19:15:47.293000+00:00)
A NULL pointer dereference vulnerability has been reported to affect several QNAP operating system versions. If a remote attacker gains an administrator account, they can then exploit the vulnerability to launch a denial-of-service (DoS) attack.

We have already fixed the vulnerability in the following versions:
QTS 5.2.6.3195 build 20250715 and later
QuTS hero h5.2.6.3195 build 20250715 and later
CVE-2025-52857 (published 2025-10-03 19:15:47.467000+00:00)
A NULL pointer dereference vulnerability has been reported to affect several QNAP operating system versions. If a remote attacker gains an administrator account, they can then exploit the vulnerability to launch a denial-of-service (DoS) attack.

We have already fixed the vulnerability in the following versions:
QTS 5.2.6.3195 build 20250715 and later
QuTS hero h5.2.6.3195 build 20250715 and later
CVE-2025-52858 (published 2025-10-03 19:15:47.620000+00:00)
A NULL pointer dereference vulnerability has been reported to affect several QNAP operating system versions. If a remote attacker gains an administrator account, they can then exploit the vulnerability to launch a denial-of-service (DoS) attack.

We have already fixed the vulnerability in the following versions:
QTS 5.2.6.3195 build 20250715 and later
QuTS hero h5.2.6.3195 build 20250715 and later
CVE-2025-52859 (published 2025-10-03 19:15:47.770000+00:00)
A NULL pointer dereference vulnerability has been reported to affect several QNAP operating system versions. If a remote attacker gains an administrator account, they can then exploit the vulnerability to launch a denial-of-service (DoS) attack.

We have already fixed the vulnerability in the following versions:
QTS 5.2.6.3195 build 20250715 and later
QuTS hero h5.2.6.3195 build 20250715 and later
CVE-2025-52860 (published 2025-10-03 19:15:47.923000+00:00)
A NULL pointer dereference vulnerability has been reported to affect several QNAP operating system versions. If a remote attacker gains an administrator account, they can then exploit the vulnerability to launch a denial-of-service (DoS) attack.

We have already fixed the vulnerability in the following versions:
QTS 5.2.6.3195 build 20250715 and later
QuTS hero h5.2.6.3195 build 20250715 and later
CVE-2025-52862 (published 2025-10-03 19:15:48.080000+00:00)
A NULL pointer dereference vulnerability has been reported to affect several QNAP operating system versions. If a remote attacker gains an administrator account, they can then exploit the vulnerability to launch a denial-of-service (DoS) attack.

We have already fixed the vulnerability in the following versions:
QTS 5.2.6.3195 build 20250715 and later
QuTS hero h5.2.6.3195 build 20250715 and later
CVE-2025-52866 (published 2025-10-03 19:15:48.233000+00:00)
A NULL pointer dereference vulnerability has been reported to affect several QNAP operating system versions. If a remote attacker gains an administrator account, they can then exploit the vulnerability to launch a denial-of-service (DoS) attack.

We have already fixed the vulnerability in the following versions:
QTS 5.2.6.3195 build 20250715 and later
QuTS hero h5.2.6.3195 build 20250715 and later
CVE-2025-52867 (published 2025-10-03 19:15:48.387000+00:00)
An uncontrolled resource consumption vulnerability has been reported to affect Qsync Central. If a remote attacker gains a user account, they can then exploit the vulnerability to launch a denial-of-service (DoS) attack.

We have already fixed the vulnerability in the following version:
Qsync Central 5.0.0.2 ( 2025/07/31 ) and later
CVE-2025-53406 (published 2025-10-03 19:15:48.543000+00:00)
A use of externally-controlled format string vulnerability has been reported to affect several QNAP operating system versions. If a remote attacker gains an administrator account, they can then exploit the vulnerability to obtain secret data or modify memory.

We have already fixed the vulnerability in the following versions:
QTS 5.2.6.3195 build 20250715 and later
QuTS hero h5.2.6.3195 build 20250715 and later
CVE-2025-53407 (published 2025-10-03 19:15:48.700000+00:00)
A use of externally-controlled format string vulnerability has been reported to affect several QNAP operating system versions. If a remote attacker gains an administrator account, they can then exploit the vulnerability to obtain secret data or modify memory.

We have already fixed the vulnerability in the following versions:
QTS 5.2.6.3195 build 20250715 and later
QuTS hero h5.2.6.3195 build 20250715 and later
CVE-2025-53595 (published 2025-10-03 19:15:48.847000+00:00)
An SQL injection vulnerability has been reported to affect Qsync Central. If a remote attacker gains a user account, they can then exploit the vulnerability to execute unauthorized code or commands.

We have already fixed the vulnerability in the following version:
Qsync Central 5.0.0.2 ( 2025/07/31 ) and later
CVE-2025-54153 (published 2025-10-03 19:15:48.997000+00:00)
An SQL injection vulnerability has been reported to affect Qsync Central. If a remote attacker gains a user account, they can then exploit the vulnerability to execute unauthorized code or commands.

We have already fixed the vulnerability in the following version:
Qsync Central 5.0.0.2 ( 2025/07/31 ) and later
CVE-2025-54154 (published 2025-10-03 19:15:49.150000+00:00)
An improper authentication vulnerability has been reported to affect QNAP Authenticator. If an attacker gains physical access, they can then exploit the vulnerability to compromise the security of the system.

We have already fixed the vulnerability in the following version:
QNAP Authenticator 1.3.1.1227 and later
CVE-2025-57714 (published 2025-10-03 19:15:50.077000+00:00)
An unquoted search path or element vulnerability has been reported to affect NetBak Replicator. If a local attacker gains a user account, they can then exploit the vulnerability to execute unauthorized code or commands.

We have already fixed the vulnerability in the following version:
NetBak Replicator 4.5.15.0807 and later
CVE-2025-49844 (published 2025-10-03 20:15:32.823000+00:00)
Redis is an open source, in-memory database that persists on disk. Versions 8.2.1 and below allow an authenticated user to use a specially crafted Lua script to manipulate the garbage collector, trigger a use-after-free and potentially lead to remote code execution. The problem exists in all versions of Redis with Lua scripting. This issue is fixed in version 8.2.2. To workaround this issue without patching the redis-server executable is to prevent users from executing Lua scripts. This can be done using ACL to restrict EVAL and EVALSHA commands.
CVE-2025-53354 (published 2025-10-03 20:15:33+00:00)
NiceGUI is a Python-based UI framework. Versions 2.24.2 and below are at risk for Cross-Site Scripting (XSS) when developers render unescaped user input into the DOM using ui.html(). NiceGUI did not enforce HTML or JavaScript sanitization, so applications that directly combine components like ui.input() with ui.html() or  ui.chat_message with HTML content without escaping may allow attackers to execute arbitrary JavaScript in the user’s browser. Applications that do not pass untrusted input into ui.html() are not affected. This issue is fixed in version 3.0.0.
CVE-2025-54374 (published 2025-10-03 20:15:33.180000+00:00)
Eidos is an extensible framework for Personal Data Management. Versions 0.21.0 and below contain a one-click remote code execution vulnerability. An attacker can exploit this vulnerability by embedding a specially crafted eidos: URL on any website, including a malicious one they control. When a victim visits such a site or clicks on the link, the browser triggers the app’s custom URL handler (eidos:), causing the Eidos application to launch and process the URL, leading to remote code execution on the victim’s machine. This issue does not have a fix as of October 3, 2025
CVE-2025-59829 (published 2025-10-03 20:15:33.653000+00:00)
Claude Code is an agentic coding tool. Versions below 1.0.120 failed to account for symlinks when checking permission deny rules. If a user explicitly denied Claude Code access to a file and Claude Code had access to a symlink pointing to that file, it was possible for Claude Code to access the file. Users on standard Claude Code auto-update will have received this fix automatically. Users performing manual updates are advised to update to the latest version. This issue is fixed in version 1.0.120.
CVE-2025-10692 (published 2025-10-03 21:15:32.373000+00:00)
The endpoint POST /api/staff/get-new-tickets concatenates the user-controlled parameter departmentId directly into the SQL WHERE clause without parameter binding. As a result, an authenticated staff user (level ≥ 1) can inject SQL to alter the filter logic, effectively bypassing department scoping and disclosing tickets beyond their intended access.This issue affects OpenSupports: 4.11.0.
CVE-2025-10696 (published 2025-10-03 21:15:33.503000+00:00)
OpenSupports exposes an endpoint that allows the list of 'supervised users' for any account to be edited, but it does not validate whether the actor is the owner of that list. A Level 1 staff member can modify the supervision relationship of a third party (the target user), who can then view the tickets of the added 'supervised' users. This breaks the authorization model and filters the content of other users' tickets.This issue affects OpenSupports: 4.11.0.
CVE-2025-59943 (published 2025-10-03 21:15:34.757000+00:00)
phpMyFAQ is an open source FAQ web application. Versions 4.0-nightly-2025-10-03 and below do not enforce uniqueness of email addresses during user registration. This allows multiple distinct accounts to be created with the same email. Because email is often used as an identifier for password resets, notifications, and administrative actions, this flaw can cause account ambiguity and, in certain configurations, may lead to privilege escalation or account takeover. This issue is fixed in version 4.0.13.
CVE-2025-59944 (published 2025-10-03 21:15:34.913000+00:00)
Cursor is a code editor built for programming with AI. Versions 1.6.23 and below contain case-sensitive checks in the way Cursor IDE protects its sensitive files (e.g., */.cursor/mcp.json), which allows attackers to modify the content of these files through prompt injection and achieve remote code execution. A prompt injection can lead to full RCE through modifying sensitive files on case-insensitive fileystems. This issue is fixed in version 1.7.
CVE-2025-43825 (published 2025-10-03 22:15:30.910000+00:00)
A vulnerability in Liferay Portal 7.4.0 through 7.4.3.132, and Liferay DXP 2025.Q1.0 through 2025.Q1.4, 2024.Q4.0 through 2024.Q4.5, 2024.Q3.0 through 2024.Q3.13, 2024.Q2.1 through 2024.Q2.13, 2024.Q1.1 through 2024.Q1.12, 2023.Q4.0 through 2023.Q4.10, 2023.Q3.1 through 2023.Q3.10, and 7.4 GA through update 92 allows sensitive user data to be included in the Freemarker template. This weakness permits an unauthorized actor to gain access to, and potentially render, confidential information that should remain restricted.
CVE-2025-61673 (published 2025-10-03 22:15:32.213000+00:00)
Karapace is an open-source implementation of Kafka REST and Schema Registry. Versions 5.0.0 and 5.0.1 contain an authentication bypass vulnerability when configured to use OAuth 2.0 Bearer Token authentication. If a request is sent without an Authorization header, the token validation logic is skipped entirely, allowing an unauthenticated user to read and write to Schema Registry endpoints that should otherwise be protected. This effectively renders the OAuth authentication mechanism ineffective. This issue is fixed in version 5.0.2.
CVE-2025-61677 (published 2025-10-03 22:15:32.390000+00:00)
DataChain is a Python-based AI-data warehouse for transforming and analyzing unstructured data. Versions 0.34.1 and below allow for deseriaization of untrusted data because of the way the DataChain library reads serialized objects from environment variables (such as DATACHAIN__METASTORE and DATACHAIN__WAREHOUSE) in the loader.py module. An attacker with the ability to set these environment variables can trigger code execution when the application loads. This issue is fixed in version 0.34.2.
CVE-2025-61679 (published 2025-10-03 22:15:32.553000+00:00)
Anyquery is an SQL query engine built on top of SQLite. Versions 0.4.3 and below allow attackers who have already gained access to localhost, even with low privileges, to use the http server through the port unauthenticated, and access private integration data like emails, without any warning of a foreign login from the provider. This issue is fixed in version 0.4.4.
CVE-2025-61681 (published 2025-10-03 22:15:32.880000+00:00)
KUNO CMS is a fully deployable full-stack blog application. Versions 1.3.13 and below contain validation flaws in its file upload functionality that can be exploited for stored XSS. The upload endpoint only validates file types based on Content-Type headers, lacks file content analysis and extension whitelist restrictions, allowing attackers to upload SVG files containing malicious scripts (disguised as images). When users access the uploaded resource pages, arbitrary JavaScript executes in their browsers. This issue is fixed in version 1.3.14.
CVE-2025-61685 (published 2025-10-03 23:15:29.870000+00:00)
Mastra is a Typescript framework for building AI agents and assistants. Versions 0.13.8 through 0.13.20-alpha.0 are vulnerable to a Directory Traversal attack that results in the disclosure of directory listings. The code contains a security check to prevent path traversal for reading file contents, but this check is effectively bypassed by subsequent logic that attempts to find directory suggestions. An attacker can leverage this flaw to list the contents of arbitrary directories on the user's filesystem, including the user's home directory, exposing sensitive information about the file system's structure. This issue is fixed in version 0.13.20.
CVE-2025-10746 (published 2025-10-04 03:15:35.860000+00:00)
The Integrate Dynamics 365 CRM plugin for WordPress is vulnerable to unauthorized access in all versions up to, and including, 1.0.9. This is due to missing capability checks and nonce verification on functions hooked to 'init'. This makes it possible for unauthenticated attackers to deactivate the plugin, tamper with OAuth configuration, and trigger test connections that expose sensitive data via direct request to vulnerable endpoints granted they can craft malicious requests with specific parameters.
CVE-2025-11227 (published 2025-10-04 03:15:36.873000+00:00)
The GiveWP – Donation Plugin and Fundraising Platform plugin for WordPress is vulnerable to Information Exposure in all versions up to, and including, 4.10.0 via the 'registerGetForm', 'registerGetForms', 'registerGetCampaign' and 'registerGetCampaigns' functions due to a missing capability check. This makes it possible for unauthenticated attackers to extract data from private and draft donation forms, as well as archived campaigns.
CVE-2025-11228 (published 2025-10-04 03:15:37.043000+00:00)
The GiveWP – Donation Plugin and Fundraising Platform plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the `registerAssociateFormsWithCampaign` function in all versions up to, and including, 4.10.0. This makes it possible for unauthenticated attackers to associate any donation forms with any campaign.
CVE-2025-8726 (published 2025-10-04 03:15:38.123000+00:00)
The WP Photo Album Plus plugin for WordPress is vulnerable to Cross-Site Scripting in all versions up to, and including, 9.0.11.006 due to insufficient input sanitization and output escaping in the wppa_user_upload function. This makes it possible for authenticated attackers, with Subscriber-level access and above, to inject arbitrary web scripts in the photo album descriptions that execute in a victim's browser.
CVE-2025-9029 (published 2025-10-04 03:15:38.290000+00:00)
The WDesignKit – Elementor & Gutenberg Starter Templates, Patterns, Cloud Workspace & Widget Builder plugin for WordPress is vulnerable to missing authorization via the wdkit_handle_review_submission function in versions less than, or equal to, 1.2.16. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for unauthenticated attackers to submit feedback data to external services.
CVE-2025-9030 (published 2025-10-04 03:15:38.450000+00:00)
The Majestic Before After Image plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'before_label' and 'after_label' parameters in versions less than, or equal to, 2.0.1 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.
CVE-2025-9243 (published 2025-10-04 03:15:38.613000+00:00)
The Cost Calculator Builder plugin for WordPress is vulnerable to unauthorizedmodification of data due to a missing capability check on the get_cc_orders and update_order_status functions in all versions up to, and including, 3.5.32. This makes it possible for authenticated attackers, with Subscriber-level access and above, to access order management functions and modify order status.
CVE-2025-9485 (published 2025-10-04 03:15:38.780000+00:00)
The OAuth Single Sign On – SSO (OAuth Client) plugin for WordPress is vulnerable to Improper Verification of Cryptographic Signature in versions up to, and including, 6.26.12. This is due to the plugin performing unsafe JWT token processing without verification or validation in the `get_resource_owner_from_id_token` function. This makes it possible for unauthenticated attackers to bypass authentication and gain access to any existing user account - including administrators in certain configurations - or to create arbitrary subscriber-level accounts.
CVE-2025-10383 (published 2025-10-04 04:16:23.820000+00:00)
The Contest Gallery – Upload, Vote & Sell with PayPal and Stripe plugin for WordPress is vulnerable to Stored Cross-Site Scripting via multiple form field parameters in all versions up to, and including, 27.0.2. This is due to insufficient input sanitization and output escaping on user-supplied attributes. This makes it possible for authenticated attackers, with author-level access or higher, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.
CVE-2025-9886 (published 2025-10-04 04:16:24.730000+00:00)
The Trinity Audio – Text to Speech AI audio player to convert content into audio plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 5.20.2. This is due to missing or incorrect nonce validation in the '/admin/inc/post-management.php' file. This makes it possible for unauthenticated attackers to activate/deactivate posts via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.
CVE-2025-9952 (published 2025-10-04 04:16:24.937000+00:00)
The Trinity Audio – Text to Speech AI audio player to convert content into audio plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via the 'range-date' parameter in all versions up to, and including, 5.20.2 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link.
CVE-2025-39931 (published 2025-10-04 08:15:45.827000+00:00)
In the Linux kernel, the following vulnerability has been resolved:

crypto: af_alg - Set merge to zero early in af_alg_sendmsg

If an error causes af_alg_sendmsg to abort, ctx->merge may contain
a garbage value from the previous loop.  This may then trigger a
crash on the next entry into af_alg_sendmsg when it attempts to do
a merge that can't be done.

Fix this by setting ctx->merge to zero near the start of the loop.
CVE-2025-39932 (published 2025-10-04 08:15:45.953000+00:00)
In the Linux kernel, the following vulnerability has been resolved:

smb: client: let smbd_destroy() call disable_work_sync(&info->post_send_credits_work)

In smbd_destroy() we may destroy the memory so we better
wait until post_send_credits_work is no longer pending
and will never be started again.

I actually just hit the case using rxe:

WARNING: CPU: 0 PID: 138 at drivers/infiniband/sw/rxe/rxe_verbs.c:1032 rxe_post_recv+0x1ee/0x480 [rdma_rxe]
...
[ 5305.686979] [    T138]  smbd_post_recv+0x445/0xc10 [cifs]
[ 5305.687135] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5
[ 5305.687149] [    T138]  ? __kasan_check_write+0x14/0x30
[ 5305.687185] [    T138]  ? __pfx_smbd_post_recv+0x10/0x10 [cifs]
[ 5305.687329] [    T138]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 5305.687356] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5
[ 5305.687368] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5
[ 5305.687378] [    T138]  ? _raw_spin_unlock_irqrestore+0x11/0x60
[ 5305.687389] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5
[ 5305.687399] [    T138]  ? get_receive_buffer+0x168/0x210 [cifs]
[ 5305.687555] [    T138]  smbd_post_send_credits+0x382/0x4b0 [cifs]
[ 5305.687701] [    T138]  ? __pfx_smbd_post_send_credits+0x10/0x10 [cifs]
[ 5305.687855] [    T138]  ? __pfx___schedule+0x10/0x10
[ 5305.687865] [    T138]  ? __pfx__raw_spin_lock_irq+0x10/0x10
[ 5305.687875] [    T138]  ? queue_delayed_work_on+0x8e/0xa0
[ 5305.687889] [    T138]  process_one_work+0x629/0xf80
[ 5305.687908] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5
[ 5305.687917] [    T138]  ? __kasan_check_write+0x14/0x30
[ 5305.687933] [    T138]  worker_thread+0x87f/0x1570
...

It means rxe_post_recv was called after rdma_destroy_qp().
This happened because put_receive_buffer() was triggered
by ib_drain_qp() and called:
queue_work(info->workqueue, &info->post_send_credits_work);
CVE-2025-39934 (published 2025-10-04 08:15:46.210000+00:00)
In the Linux kernel, the following vulnerability has been resolved:

drm: bridge: anx7625: Fix NULL pointer dereference with early IRQ

If the interrupt occurs before resource initialization is complete, the
interrupt handler/worker may access uninitialized data such as the I2C
tcpc_client device, potentially leading to NULL pointer dereference.
CVE-2025-39935 (published 2025-10-04 08:15:46.333000+00:00)
In the Linux kernel, the following vulnerability has been resolved:

ASoC: codec: sma1307: Fix memory corruption in sma1307_setting_loaded()

The sma1307->set.header_size is how many integers are in the header
(there are 8 of them) but instead of allocating space of 8 integers
we allocate 8 bytes.  This leads to memory corruption when we copy data
it on the next line:

        memcpy(sma1307->set.header, data,
               sma1307->set.header_size * sizeof(int));

Also since we're immediately copying over the memory in ->set.header,
there is no need to zero it in the allocator.  Use devm_kmalloc_array()
to allocate the memory instead.
CVE-2025-39936 (published 2025-10-04 08:15:46.460000+00:00)
In the Linux kernel, the following vulnerability has been resolved:

crypto: ccp - Always pass in an error pointer to __sev_platform_shutdown_locked()

When

  9770b428b1a2 ("crypto: ccp - Move dev_info/err messages for SEV/SNP init and shutdown")

moved the error messages dumping so that they don't need to be issued by
the callers, it missed the case where __sev_firmware_shutdown() calls
__sev_platform_shutdown_locked() with a NULL argument which leads to
a NULL ptr deref on the shutdown path, during suspend to disk:

  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: Oops: 0000 [#1] SMP NOPTI
  CPU: 0 UID: 0 PID: 983 Comm: hib.sh Not tainted 6.17.0-rc4+ #1 PREEMPT(voluntary)
  Hardware name: Supermicro Super Server/H12SSL-i, BIOS 2.5 09/08/2022
  RIP: 0010:__sev_platform_shutdown_locked.cold+0x0/0x21 [ccp]

That rIP is:

  00000000000006fd <__sev_platform_shutdown_locked.cold>:
   6fd:   8b 13                   mov    (%rbx),%edx
   6ff:   48 8b 7d 00             mov    0x0(%rbp),%rdi
   703:   89 c1                   mov    %eax,%ecx

  Code: 74 05 31 ff 41 89 3f 49 8b 3e 89 ea 48 c7 c6 a0 8e 54 a0 41 bf 92 ff ff ff e8 e5 2e 09 e1 c6 05 2a d4 38 00 01 e9 26 af ff ff <8b> 13 48 8b 7d 00 89 c1 48 c7 c6 18 90 54 a0 89 44 24 04 e8 c1 2e
  RSP: 0018:ffffc90005467d00 EFLAGS: 00010282
  RAX: 00000000ffffff92 RBX: 0000000000000000 RCX: 0000000000000000
  			     ^^^^^^^^^^^^^^^^
and %rbx is nice and clean.

  Call Trace:
   <TASK>
   __sev_firmware_shutdown.isra.0
   sev_dev_destroy
   psp_dev_destroy
   sp_destroy
   pci_device_shutdown
   device_shutdown
   kernel_power_off
   hibernate.cold
   state_store
   kernfs_fop_write_iter
   vfs_write
   ksys_write
   do_syscall_64
   entry_SYSCALL_64_after_hwframe

Pass in a pointer to the function-local error var in the caller.

With that addressed, suspending the ccp shows the error properly at
least:

  ccp 0000:47:00.1: sev command 0x2 timed out, disabling PSP
  ccp 0000:47:00.1: SEV: failed to SHUTDOWN error 0x0, rc -110
  SEV-SNP: Leaking PFN range 0x146800-0x146a00
  SEV-SNP: PFN 0x146800 unassigned, dumping non-zero entries in 2M PFN region: [0x146800 - 0x146a00]
  ...
  ccp 0000:47:00.1: SEV-SNP firmware shutdown failed, rc -16, error 0x0
  ACPI: PM: Preparing to enter system sleep state S5
  kvm: exiting hardware virtualization
  reboot: Power down

Btw, this driver is crying to be cleaned up to pass in a proper I/O
struct which can be used to store information between the different
functions, otherwise stuff like that will happen in the future again.
CVE-2025-39937 (published 2025-10-04 08:15:46.593000+00:00)
In the Linux kernel, the following vulnerability has been resolved:

net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer

Since commit 7d5e9737efda ("net: rfkill: gpio: get the name and type from
device property") rfkill_find_type() gets called with the possibly
uninitialized "const char *type_name;" local variable.

On x86 systems when rfkill-gpio binds to a "BCM4752" or "LNV4752"
acpi_device, the rfkill->type is set based on the ACPI acpi_device_id:

        rfkill->type = (unsigned)id->driver_data;

and there is no "type" property so device_property_read_string() will fail
and leave type_name uninitialized, leading to a potential crash.

rfkill_find_type() does accept a NULL pointer, fix the potential crash
by initializing type_name to NULL.

Note likely sofar this has not been caught because:

1. Not many x86 machines actually have a "BCM4752"/"LNV4752" acpi_device
2. The stack happened to contain NULL where type_name is stored
CVE-2025-39938 (published 2025-10-04 08:15:46.730000+00:00)
In the Linux kernel, the following vulnerability has been resolved:

ASoC: qcom: q6apm-lpass-dais: Fix NULL pointer dereference if source graph failed

If earlier opening of source graph fails (e.g. ADSP rejects due to
incorrect audioreach topology), the graph is closed and
"dai_data->graph[dai->id]" is assigned NULL.  Preparing the DAI for sink
graph continues though and next call to q6apm_lpass_dai_prepare()
receives dai_data->graph[dai->id]=NULL leading to NULL pointer
exception:

  qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001002 cmd
  qcom-apm gprsvc:service:2:1: DSP returned error[1001002] 1
  q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: fail to start APM port 78
  q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC: error at snd_soc_pcm_dai_prepare on TX_CODEC_DMA_TX_3: -22
  Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a8
  ...
  Call trace:
   q6apm_graph_media_format_pcm+0x48/0x120 (P)
   q6apm_lpass_dai_prepare+0x110/0x1b4
   snd_soc_pcm_dai_prepare+0x74/0x108
   __soc_pcm_prepare+0x44/0x160
   dpcm_be_dai_prepare+0x124/0x1c0
CVE-2025-39939 (published 2025-10-04 08:15:46.860000+00:00)
In the Linux kernel, the following vulnerability has been resolved:

iommu/s390: Fix memory corruption when using identity domain

zpci_get_iommu_ctrs() returns counter information to be reported as part
of device statistics; these counters are stored as part of the s390_domain.
The problem, however, is that the identity domain is not backed by an
s390_domain and so the conversion via to_s390_domain() yields a bad address
that is zero'd initially and read on-demand later via a sysfs read.
These counters aren't necessary for the identity domain; just return NULL
in this case.

This issue was discovered via KASAN with reports that look like:
BUG: KASAN: global-out-of-bounds in zpci_fmb_enable_device
when using the identity domain for a device on s390.
CVE-2025-39940 (published 2025-10-04 08:15:46.973000+00:00)
In the Linux kernel, the following vulnerability has been resolved:

dm-stripe: fix a possible integer overflow

There's a possible integer overflow in stripe_io_hints if we have too
large chunk size. Test if the overflow happened, and if it did, don't set
limits->io_min and limits->io_opt;
CVE-2025-39941 (published 2025-10-04 08:15:47.103000+00:00)
In the Linux kernel, the following vulnerability has been resolved:

zram: fix slot write race condition

Parallel concurrent writes to the same zram index result in leaked
zsmalloc handles.  Schematically we can have something like this:

CPU0                              CPU1
zram_slot_lock()
zs_free(handle)
zram_slot_lock()
				zram_slot_lock()
				zs_free(handle)
				zram_slot_lock()

compress			compress
handle = zs_malloc()		handle = zs_malloc()
zram_slot_lock
zram_set_handle(handle)
zram_slot_lock
				zram_slot_lock
				zram_set_handle(handle)
				zram_slot_lock

Either CPU0 or CPU1 zsmalloc handle will leak because zs_free() is done
too early.  In fact, we need to reset zram entry right before we set its
new handle, all under the same slot lock scope.
CVE-2025-39943 (published 2025-10-04 08:15:47.357000+00:00)
In the Linux kernel, the following vulnerability has been resolved:

ksmbd: smbdirect: validate data_offset and data_length field of smb_direct_data_transfer

If data_offset and data_length of smb_direct_data_transfer struct are
invalid, out of bounds issue could happen.
This patch validate data_offset and data_length field in recv_done.
CVE-2025-39944 (published 2025-10-04 08:15:47.480000+00:00)
In the Linux kernel, the following vulnerability has been resolved:

octeontx2-pf: Fix use-after-free bugs in otx2_sync_tstamp()

The original code relies on cancel_delayed_work() in otx2_ptp_destroy(),
which does not ensure that the delayed work item synctstamp_work has fully
completed if it was already running. This leads to use-after-free scenarios
where otx2_ptp is deallocated by otx2_ptp_destroy(), while synctstamp_work
remains active and attempts to dereference otx2_ptp in otx2_sync_tstamp().
Furthermore, the synctstamp_work is cyclic, the likelihood of triggering
the bug is nonnegligible.

A typical race condition is illustrated below:

CPU 0 (cleanup)           | CPU 1 (delayed work callback)
otx2_remove()             |
  otx2_ptp_destroy()      | otx2_sync_tstamp()
    cancel_delayed_work() |
    kfree(ptp)            |
                          |   ptp = container_of(...); //UAF
                          |   ptp-> //UAF

This is confirmed by a KASAN report:

BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0
Write of size 8 at addr ffff88800aa09a18 by task bash/136
...
Call Trace:
 <IRQ>
 dump_stack_lvl+0x55/0x70
 print_report+0xcf/0x610
 ? __run_timer_base.part.0+0x7d7/0x8c0
 kasan_report+0xb8/0xf0
 ? __run_timer_base.part.0+0x7d7/0x8c0
 __run_timer_base.part.0+0x7d7/0x8c0
 ? __pfx___run_timer_base.part.0+0x10/0x10
 ? __pfx_read_tsc+0x10/0x10
 ? ktime_get+0x60/0x140
 ? lapic_next_event+0x11/0x20
 ? clockevents_program_event+0x1d4/0x2a0
 run_timer_softirq+0xd1/0x190
 handle_softirqs+0x16a/0x550
 irq_exit_rcu+0xaf/0xe0
 sysvec_apic_timer_interrupt+0x70/0x80
 </IRQ>
...
Allocated by task 1:
 kasan_save_stack+0x24/0x50
 kasan_save_track+0x14/0x30
 __kasan_kmalloc+0x7f/0x90
 otx2_ptp_init+0xb1/0x860
 otx2_probe+0x4eb/0xc30
 local_pci_probe+0xdc/0x190
 pci_device_probe+0x2fe/0x470
 really_probe+0x1ca/0x5c0
 __driver_probe_device+0x248/0x310
 driver_probe_device+0x44/0x120
 __driver_attach+0xd2/0x310
 bus_for_each_dev+0xed/0x170
 bus_add_driver+0x208/0x500
 driver_register+0x132/0x460
 do_one_initcall+0x89/0x300
 kernel_init_freeable+0x40d/0x720
 kernel_init+0x1a/0x150
 ret_from_fork+0x10c/0x1a0
 ret_from_fork_asm+0x1a/0x30

Freed by task 136:
 kasan_save_stack+0x24/0x50
 kasan_save_track+0x14/0x30
 kasan_save_free_info+0x3a/0x60
 __kasan_slab_free+0x3f/0x50
 kfree+0x137/0x370
 otx2_ptp_destroy+0x38/0x80
 otx2_remove+0x10d/0x4c0
 pci_device_remove+0xa6/0x1d0
 device_release_driver_internal+0xf8/0x210
 pci_stop_bus_device+0x105/0x150
 pci_stop_and_remove_bus_device_locked+0x15/0x30
 remove_store+0xcc/0xe0
 kernfs_fop_write_iter+0x2c3/0x440
 vfs_write+0x871/0xd70
 ksys_write+0xee/0x1c0
 do_syscall_64+0xac/0x280
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
...

Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure
that the delayed work item is properly canceled before the otx2_ptp is
deallocated.

This bug was initially identified through static analysis. To reproduce
and test it, I simulated the OcteonTX2 PCI device in QEMU and introduced
artificial delays within the otx2_sync_tstamp() function to increase the
likelihood of triggering the bug.
CVE-2025-39945 (published 2025-10-04 08:15:47.613000+00:00)
In the Linux kernel, the following vulnerability has been resolved:

cnic: Fix use-after-free bugs in cnic_delete_task

The original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(),
which does not guarantee that the delayed work item 'delete_task' has
fully completed if it was already running. Additionally, the delayed work
item is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only
blocks and waits for work items that were already queued to the
workqueue prior to its invocation. Any work items submitted after
flush_workqueue() is called are not included in the set of tasks that the
flush operation awaits. This means that after the cyclic work items have
finished executing, a delayed work item may still exist in the workqueue.
This leads to use-after-free scenarios where the cnic_dev is deallocated
by cnic_free_dev(), while delete_task remains active and attempt to
dereference cnic_dev in cnic_delete_task().

A typical race condition is illustrated below:

CPU 0 (cleanup)              | CPU 1 (delayed work callback)
cnic_netdev_event()          |
  cnic_stop_hw()             | cnic_delete_task()
    cnic_cm_stop_bnx2x_hw()  | ...
      cancel_delayed_work()  | /* the queue_delayed_work()
      flush_workqueue()      |    executes after flush_workqueue()*/
                             | queue_delayed_work()
  cnic_free_dev(dev)//free   | cnic_delete_task() //new instance
                             |   dev = cp->dev; //use

Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure
that the cyclic delayed work item is properly canceled and that any
ongoing execution of the work item completes before the cnic_dev is
deallocated. Furthermore, since cancel_delayed_work_sync() uses
__flush_work(work, true) to synchronously wait for any currently
executing instance of the work item to finish, the flush_workqueue()
becomes redundant and should be removed.

This bug was identified through static analysis. To reproduce the issue
and validate the fix, I simulated the cnic PCI device in QEMU and
introduced intentional delays — such as inserting calls to ssleep()
within the cnic_delete_task() function — to increase the likelihood
of triggering the bug.
CVE-2025-39946 (published 2025-10-04 08:15:47.747000+00:00)
In the Linux kernel, the following vulnerability has been resolved:

tls: make sure to abort the stream if headers are bogus

Normally we wait for the socket to buffer up the whole record
before we service it. If the socket has a tiny buffer, however,
we read out the data sooner, to prevent connection stalls.
Make sure that we abort the connection when we find out late
that the record is actually invalid. Retrying the parsing is
fine in itself but since we copy some more data each time
before we parse we can overflow the allocated skb space.

Constructing a scenario in which we're under pressure without
enough data in the socket to parse the length upfront is quite
hard. syzbot figured out a way to do this by serving us the header
in small OOB sends, and then filling in the recvbuf with a large
normal send.

Make sure that tls_rx_msg_size() aborts strp, if we reach
an invalid record there's really no way to recover.
CVE-2025-39947 (published 2025-10-04 08:15:47.867000+00:00)
In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Harden uplink netdev access against device unbind

The function mlx5_uplink_netdev_get() gets the uplink netdevice
pointer from mdev->mlx5e_res.uplink_netdev. However, the netdevice can
be removed and its pointer cleared when unbound from the mlx5_core.eth
driver. This results in a NULL pointer, causing a kernel panic.

 BUG: unable to handle page fault for address: 0000000000001300
 at RIP: 0010:mlx5e_vport_rep_load+0x22a/0x270 [mlx5_core]
 Call Trace:
  <TASK>
  mlx5_esw_offloads_rep_load+0x68/0xe0 [mlx5_core]
  esw_offloads_enable+0x593/0x910 [mlx5_core]
  mlx5_eswitch_enable_locked+0x341/0x420 [mlx5_core]
  mlx5_devlink_eswitch_mode_set+0x17e/0x3a0 [mlx5_core]
  devlink_nl_eswitch_set_doit+0x60/0xd0
  genl_family_rcv_msg_doit+0xe0/0x130
  genl_rcv_msg+0x183/0x290
  netlink_rcv_skb+0x4b/0xf0
  genl_rcv+0x24/0x40
  netlink_unicast+0x255/0x380
  netlink_sendmsg+0x1f3/0x420
  __sock_sendmsg+0x38/0x60
  __sys_sendto+0x119/0x180
  do_syscall_64+0x53/0x1d0
  entry_SYSCALL_64_after_hwframe+0x4b/0x53

Ensure the pointer is valid before use by checking it for NULL. If it
is valid, immediately call netdev_hold() to take a reference, and
preventing the netdevice from being freed while it is in use.
CVE-2025-39949 (published 2025-10-04 08:15:48.120000+00:00)
In the Linux kernel, the following vulnerability has been resolved:

qed: Don't collect too many protection override GRC elements

In the protection override dump path, the firmware can return far too
many GRC elements, resulting in attempting to write past the end of the
previously-kmalloc'ed dump buffer.

This will result in a kernel panic with reason:

 BUG: unable to handle kernel paging request at ADDRESS

where "ADDRESS" is just past the end of the protection override dump
buffer. The start address of the buffer is:
 p_hwfn->cdev->dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_buf
and the size of the buffer is buf_size in the same data structure.

The panic can be arrived at from either the qede Ethernet driver path:

    [exception RIP: qed_grc_dump_addr_range+0x108]
 qed_protection_override_dump at ffffffffc02662ed [qed]
 qed_dbg_protection_override_dump at ffffffffc0267792 [qed]
 qed_dbg_feature at ffffffffc026aa8f [qed]
 qed_dbg_all_data at ffffffffc026b211 [qed]
 qed_fw_fatal_reporter_dump at ffffffffc027298a [qed]
 devlink_health_do_dump at ffffffff82497f61
 devlink_health_report at ffffffff8249cf29
 qed_report_fatal_error at ffffffffc0272baf [qed]
 qede_sp_task at ffffffffc045ed32 [qede]
 process_one_work at ffffffff81d19783

or the qedf storage driver path:

    [exception RIP: qed_grc_dump_addr_range+0x108]
 qed_protection_override_dump at ffffffffc068b2ed [qed]
 qed_dbg_protection_override_dump at ffffffffc068c792 [qed]
 qed_dbg_feature at ffffffffc068fa8f [qed]
 qed_dbg_all_data at ffffffffc0690211 [qed]
 qed_fw_fatal_reporter_dump at ffffffffc069798a [qed]
 devlink_health_do_dump at ffffffff8aa95e51
 devlink_health_report at ffffffff8aa9ae19
 qed_report_fatal_error at ffffffffc0697baf [qed]
 qed_hw_err_notify at ffffffffc06d32d7 [qed]
 qed_spq_post at ffffffffc06b1011 [qed]
 qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed]
 qedf_cleanup_fcport at ffffffffc05e7597 [qedf]
 qedf_rport_event_handler at ffffffffc05e7bf7 [qedf]
 fc_rport_work at ffffffffc02da715 [libfc]
 process_one_work at ffffffff8a319663

Resolve this by clamping the firmware's return value to the maximum
number of legal elements the firmware should return.
CVE-2025-39950 (published 2025-10-04 08:15:48.253000+00:00)
In the Linux kernel, the following vulnerability has been resolved:

net/tcp: Fix a NULL pointer dereference when using TCP-AO with TCP_REPAIR

A NULL pointer dereference can occur in tcp_ao_finish_connect() during a
connect() system call on a socket with a TCP-AO key added and TCP_REPAIR
enabled.

The function is called with skb being NULL and attempts to dereference it
on tcp_hdr(skb)->seq without a prior skb validation.

Fix this by checking if skb is NULL before dereferencing it.

The commentary is taken from bpf_skops_established(), which is also called
in the same flow. Unlike the function being patched,
bpf_skops_established() validates the skb before dereferencing it.

int main(void){
	struct sockaddr_in sockaddr;
	struct tcp_ao_add tcp_ao;
	int sk;
	int one = 1;

	memset(&sockaddr,'\0',sizeof(sockaddr));
	memset(&tcp_ao,'\0',sizeof(tcp_ao));

	sk = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);

	sockaddr.sin_family = AF_INET;

	memcpy(tcp_ao.alg_name,"cmac(aes128)",12);
	memcpy(tcp_ao.key,"ABCDEFGHABCDEFGH",16);
	tcp_ao.keylen = 16;

	memcpy(&tcp_ao.addr,&sockaddr,sizeof(sockaddr));

	setsockopt(sk, IPPROTO_TCP, TCP_AO_ADD_KEY, &tcp_ao,
	sizeof(tcp_ao));
	setsockopt(sk, IPPROTO_TCP, TCP_REPAIR, &one, sizeof(one));

	sockaddr.sin_family = AF_INET;
	sockaddr.sin_port = htobe16(123);

	inet_aton("127.0.0.1", &sockaddr.sin_addr);

	connect(sk,(struct sockaddr *)&sockaddr,sizeof(sockaddr));

return 0;
}

$ gcc tcp-ao-nullptr.c -o tcp-ao-nullptr -Wall
$ unshare -Urn

BUG: kernel NULL pointer dereference, address: 00000000000000b6
PGD 1f648d067 P4D 1f648d067 PUD 1982e8067 PMD 0
Oops: Oops: 0000 [#1] SMP NOPTI
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop
Reference Platform, BIOS 6.00 11/12/2020
RIP: 0010:tcp_ao_finish_connect (net/ipv4/tcp_ao.c:1182)
CVE-2025-39951 (published 2025-10-04 08:15:48.380000+00:00)
In the Linux kernel, the following vulnerability has been resolved:

um: virtio_uml: Fix use-after-free after put_device in probe

When register_virtio_device() fails in virtio_uml_probe(),
the code sets vu_dev->registered = 1 even though
the device was not successfully registered.
This can lead to use-after-free or other issues.
CVE-2025-39952 (published 2025-10-04 08:15:48.507000+00:00)
In the Linux kernel, the following vulnerability has been resolved:

wifi: wilc1000: avoid buffer overflow in WID string configuration

Fix the following copy overflow warning identified by Smatch checker.

 drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame()
        error: '__memcpy()' 'cfg->s[i]->str' copy overflow (512 vs 65537)

This patch introduces size check before accessing the memory buffer.
The checks are base on the WID type of received data from the firmware.
For WID string configuration, the size limit is determined by individual
element size in 'struct wilc_cfg_str_vals' that is maintained in 'len' field
of 'struct wilc_cfg_str'.
CVE-2025-39953 (published 2025-10-04 08:15:48.627000+00:00)
In the Linux kernel, the following vulnerability has been resolved:

cgroup: split cgroup_destroy_wq into 3 workqueues

A hung task can occur during [1] LTP cgroup testing when repeatedly
mounting/unmounting perf_event and net_prio controllers with
systemd.unified_cgroup_hierarchy=1. The hang manifests in
cgroup_lock_and_drain_offline() during root destruction.

Related case:
cgroup_fj_function_perf_event cgroup_fj_function.sh perf_event
cgroup_fj_function_net_prio cgroup_fj_function.sh net_prio

Call Trace:
	cgroup_lock_and_drain_offline+0x14c/0x1e8
	cgroup_destroy_root+0x3c/0x2c0
	css_free_rwork_fn+0x248/0x338
	process_one_work+0x16c/0x3b8
	worker_thread+0x22c/0x3b0
	kthread+0xec/0x100
	ret_from_fork+0x10/0x20

Root Cause:

CPU0                            CPU1
mount perf_event                umount net_prio
cgroup1_get_tree                cgroup_kill_sb
rebind_subsystems               // root destruction enqueues
				// cgroup_destroy_wq
// kill all perf_event css
                                // one perf_event css A is dying
                                // css A offline enqueues cgroup_destroy_wq
                                // root destruction will be executed first
                                css_free_rwork_fn
                                cgroup_destroy_root
                                cgroup_lock_and_drain_offline
                                // some perf descendants are dying
                                // cgroup_destroy_wq max_active = 1
                                // waiting for css A to die

Problem scenario:
1. CPU0 mounts perf_event (rebind_subsystems)
2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work
3. A dying perf_event CSS gets queued for offline after root destruction
4. Root destruction waits for offline completion, but offline work is
   blocked behind root destruction in cgroup_destroy_wq (max_active=1)

Solution:
Split cgroup_destroy_wq into three dedicated workqueues:
cgroup_offline_wq – Handles CSS offline operations
cgroup_release_wq – Manages resource release
cgroup_free_wq – Performs final memory deallocation

This separation eliminates blocking in the CSS free path while waiting for
offline operations to complete.

[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers
CVE-2022-50470 (published 2025-10-04 16:15:42.380000+00:00)
In the Linux kernel, the following vulnerability has been resolved:

xhci: Remove device endpoints from bandwidth list when freeing the device

Endpoints are normally deleted from the bandwidth list when they are
dropped, before the virt device is freed.

If xHC host is dying or being removed then the endpoints aren't dropped
cleanly due to functions returning early to avoid interacting with a
non-accessible host controller.

So check and delete endpoints that are still on the bandwidth list when
freeing the virt device.

Solves a list_del corruption kernel crash when unbinding xhci-pci,
caused by xhci_mem_cleanup() when it later tried to delete already freed
endpoints from the bandwidth list.

This only affects hosts that use software bandwidth checking, which
currenty is only the xHC in intel Panther Point PCH (Ivy Bridge)
CVE-2022-50472 (published 2025-10-04 16:15:43.673000+00:00)
In the Linux kernel, the following vulnerability has been resolved:

IB/mad: Don't call to function that might sleep while in atomic context

Tracepoints are not allowed to sleep, as such the following splat is
generated due to call to ib_query_pkey() in atomic context.

WARNING: CPU: 0 PID: 1888000 at kernel/trace/ring_buffer.c:2492 rb_commit+0xc1/0x220
CPU: 0 PID: 1888000 Comm: kworker/u9:0 Kdump: loaded Tainted: G           OE    --------- -  - 4.18.0-305.3.1.el8.x86_64 #1
 Hardware name: Red Hat KVM, BIOS 1.13.0-2.module_el8.3.0+555+a55c8938 04/01/2014
 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]
 RIP: 0010:rb_commit+0xc1/0x220
 RSP: 0000:ffffa8ac80f9bca0 EFLAGS: 00010202
 RAX: ffff8951c7c01300 RBX: ffff8951c7c14a00 RCX: 0000000000000246
 RDX: ffff8951c707c000 RSI: ffff8951c707c57c RDI: ffff8951c7c14a00
 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
 R10: ffff8951c7c01300 R11: 0000000000000001 R12: 0000000000000246
 R13: 0000000000000000 R14: ffffffff964c70c0 R15: 0000000000000000
 FS:  0000000000000000(0000) GS:ffff8951fbc00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 00007f20e8f39010 CR3: 000000002ca10005 CR4: 0000000000170ef0
 Call Trace:
  ring_buffer_unlock_commit+0x1d/0xa0
  trace_buffer_unlock_commit_regs+0x3b/0x1b0
  trace_event_buffer_commit+0x67/0x1d0
  trace_event_raw_event_ib_mad_recv_done_handler+0x11c/0x160 [ib_core]
  ib_mad_recv_done+0x48b/0xc10 [ib_core]
  ? trace_event_raw_event_cq_poll+0x6f/0xb0 [ib_core]
  __ib_process_cq+0x91/0x1c0 [ib_core]
  ib_cq_poll_work+0x26/0x80 [ib_core]
  process_one_work+0x1a7/0x360
  ? create_worker+0x1a0/0x1a0
  worker_thread+0x30/0x390
  ? create_worker+0x1a0/0x1a0
  kthread+0x116/0x130
  ? kthread_flush_work_fn+0x10/0x10
  ret_from_fork+0x35/0x40
 ---[ end trace 78ba8509d3830a16 ]---