CVE-2025-38096

Published Jul 3, 2025

Last updated 8 months ago

CVSS medium 5.5

Overview

Description
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: don't warn when if there is a FW error iwl_trans_reclaim is warning if it is called when the FW is not alive. But if it is called when there is a pending restart, i.e. after a FW error, there is no need to warn, instead - return silently.
Source
416baaa9-dc9f-4396-8d5f-8c081fb06d67
NVD status
Analyzed
Products
linux_kernel

Risk scores

CVSS 3.1

Type
Primary
Base score
5.5
Impact score
3.6
Exploitability score
1.8
Vector string
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Severity
MEDIUM

Weaknesses

nvd@nist.gov
NVD-CWE-noinfo

Social media

Hype score
Not currently trending

  1. CVE-2025-38096: Is Intel's Silent Firmware Error a Security Risk or a Minor Flaw? https://t.co/0xtfcBHLyR #CVE2025 #IntelSecurity #FirmwareFlaws

    @cyber_newsroom

    13 Jul 2026

    0 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  2. CVE-2025-38096: Intel's iwlwifi Driver Doesn't Alert on Firmware Errors https://t.co/Cra8EHscD9 #CVE2025 #Intel #iwlwifi

    @cyber_newsroom

    13 Jul 2026

    0 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  3. CVE-2025-38096: Intel's Silence on Firmware Errors Raises Operational Risks https://t.co/i9fmeNLEvS #CVE2025 #Intel #CyberSecurity

    @cyber_newsroom

    13 Jul 2026

    0 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  4. CVE-2025-38096: Intel's iwlwifi Driver Fails to Warn Users of Firmware Errors https://t.co/Wj4HN7BgkR #CVE2025 #Intel #iwlwifi

    @cyber_newsroom

    13 Jul 2026

    0 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  5. CVE-2025-38096: Intel's iwlwifi Fails on Critical Firmware Error Notification https://t.co/cTjZM7yMX4 #CVE2025 #CyberSecurity #Intel

    @cyber_newsroom

    13 Jul 2026

    0 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  6. CVE-2025-38096: iwlwifi's Silent Firmware Errors Are a Wake-Up Call https://t.co/wUW6FWolZ1 #CVE2025 #CyberSecurity #FirmwareErrors

    @cyber_newsroom

    13 Jul 2026

    0 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  7. CVE-2025-38096 In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: don't warn when if there is a FW error iwl_trans_reclaim is warning if it is call… https://t.co/rIAwfBzvni

    @CVEnew

    3 Jul 2025

    191 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

Configurations

Related CVEs

  1. In the Linux kernel, the following vulnerability has been resolved: virtiofs: fix UAF on submount umount iput() called from fuse_release_end() can Oops if the super block has already been destroyed. Normally this is prevented by waiting for num_waiting to go down to zero before commencing with super block shutdown. This only works, however, for the last submount instance, as the wait counter is per connection, not per superblock. Revert to using synchronous release requests for the auto_submounts case, which is virtiofs only at this time.•CVE-2026-53381
  2. In the Linux kernel, the following vulnerability has been resolved: media: rzv2h-ivc: Fix concurrent buffer list access The list of buffers (`rzv2h_ivc::buffers.queue`) is protected by a spinlock (`rzv2h_ivc::buffers.lock`). However, in `rzv2h_ivc_transfer_buffer()`, which runs in a separate workqueue, the `list_del()` call is executed without holding the spinlock, which makes it possible for the list to be concurrently modified Fix that by removing a buffer from the list in the lock protected section. [assign ivc->buffers.curr in critical section as reported by Barnabas]•CVE-2026-53380
  3. In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov8856: free control handler on error in ov8856_init_controls() The control handler wasn't freed if adding controls failed, add an error exit label and convert the existing error return to use it.•CVE-2026-53379
  4. In the Linux kernel, the following vulnerability has been resolved: drm/colorop: Fix blob property reference tracking in state lifecycle The colorop state blob property handling had memory leaks during state duplication, destruction, and reset operations. The implementation failed to follow the established pattern from drm_crtc's handling of DEGAMMA/GAMMA blob properties. Issues fixed: - drm_colorop_atomic_destroy_state() was freeing state memory without releasing the blob reference, causing a leak - drm_colorop_reset() was directly freeing old state with kfree() instead of properly destroying it, leaking blob references - drm_colorop_cleanup() had duplicate blob cleanup code Changes: - Add __drm_atomic_helper_colorop_destroy_state() helper to properly release blob references before freeing state memory - Update drm_colorop_atomic_destroy_state() to call the helper - Fix drm_colorop_reset() to use drm_colorop_atomic_destroy_state() for proper cleanup of old state - Simplify drm_colorop_cleanup() to use the common destruction path This matches the well-tested pattern used by drm_crtc since 2016 and ensures proper reference counting throughout the state lifecycle. Co-developed by Claude Sonnet 4.5.•CVE-2026-53378
  5. In the Linux kernel, the following vulnerability has been resolved: drm/msm: always recover the gpu Previously, in case there was no more work to do, recover worker wouldn't trigger recovery and would instead rely on the gpu going to sleep and then resuming when more work is submitted. Recover_worker will first increment the fence of the hung ring so, if there's only one job submitted to a ring and that causes an hang, it will early out. There's no guarantee that the gpu will suspend and resume before more work is submitted and if the gpu is in a hung state it will stay in that state and probably trigger a timeout again. Just stop checking and always recover the gpu. Patchwork: https://patchwork.freedesktop.org/patch/704066/•CVE-2026-53377

References

Sources include official advisories and independent security research.