Red Hat Linux Security Advisories & CVEs
15893 advisories tracked · Red Hat Security Data API · direct feeds checked every minute; rate-limited sources checked less often
Get an email when Red Hat publishes the next one.
See Red Hat's last 90 days of advisories first. Then choose one product with live alerts free for life, or a free month of real-time alerts on everything with the severity, the fixed version and the vendor's link (card needed, then US$15/month; we email you before the first charge).
iPhone and Android apps · New on the App Store
Monitor Red Hat CVEs from your phone.
Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 34 official vendor sources and 160+ reviewed platform categories.
Security advisories for your Red Hat release
Pick your distribution release to see every advisory issued for it and its severity mix. Fixes ship as errata, so keep the system patched. This is the release's advisory history, not a per-package scan.
Official source
Red Hat Security Data API
Red Hat Enterprise Linux errata (RHSA) via the official Red Hat Security Data API — CVE severity, CVSS and affected packages. A credential-free official source.
Latest Red Hat advisories
Medium [CVE-2026-63900] fix missing indat transfer sanity check
In the Linux kernel, the following vulnerability has been resolved: USB: serial: keyspan: fix missing indat transfer sanity check Add the missing sanity check on the size of usa49wg indat transfers to avoid parsing stale or uninitialised slab data. This oversight could allow an attacker to cause the system to parse stale or uninitialized memory, potentially leading to information disclosure. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-824. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9. Will not fix / out of support: Red Hat Enterprise Linux 6. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-63902] validate interrupt packet headers
In the Linux kernel, the following vulnerability has been resolved: USB: serial: cypress_m8: validate interrupt packet headers cypress_read_int_callback() parses the interrupt-in buffer according to the selected Cypress packet format. Format 1 has a two-byte status/count header and format 2 has a one-byte combined status/count header. The usb-serial core sizes the interrupt-in buffer from the endpoint descriptor's wMaxPacketSize, and successful interrupt transfers can complete short when URB_SHORT_NOT_OK is not set. Check that the completed packet contains the selected header before reading it. Malformed short reports are ignored and the interrupt URB is resubmitted through the existing retry path, preventing out-of-bounds header-byte reads. KASAN report as below: KASAN slab-out-of-bounds in cypress_read_int_callback+0x240/0x7f0 Read of size 1 Call trace: cypress_read_int_callback() (drivers/usb/serial/cypress_m8.c:1009) __usb_hcd_giveback_urb() dummy_timer() [ johan: use constants in header length sanity checks ] This vulnerability allows a local attacker to cause a denial of service (DoS) due to an out-of-bounds read. The `cypress_read_int_callback()` function does not properly validate the length of interrupt packets, leading to attempts to read beyond allocated memory when processing malformed short reports. This can result in system instability.
Medium [CVE-2026-63911] reset runtime state when cloning SAs
In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: reset runtime state when cloning SAs iptfs_clone_state() clones the IPTFS mode data with kmemdup(). This copies runtime objects which must not be shared with the original SA, including the embedded sk_buff_head, hrtimers, spinlock, and in-flight reassembly/reorder state. If xfrm_state_migrate() fails after clone_state() but before the later init_state() call has reinitialized those fields, the cloned state can be destroyed by xfrm_state_gc_task() with list and timer state copied from the original SA. With queued packets this lets the clone splice and free skbs owned by the original IPTFS queue, leading to use-after-free and double-free reports in iptfs_destroy_state() and skb release paths. Reinitialize the clone's runtime state before publishing it through x->mode_data. Because clone_state() now publishes a destroyable mode_data object before init_state(), take the mode callback module reference there. Avoid taking it again from __iptfs_init_state() for the same object. This vulnerability arises from incorrect handling of runtime data when cloning Security Associations (SAs). If a state migration fails, the cloned state can improperly share memory with the original, leading to use-after-free and double-free conditions.
Medium [CVE-2026-63876] Convert to use a platform device
In the Linux kernel, the following vulnerability has been resolved: serial: zs: Convert to use a platform device Prevent a crash from happening as the first serial port is initialised: Console: switching to mono frame buffer device 160x64 fb0: PMAG-AA frame buffer device at tc0 DECstation Z85C30 serial driver version 0.10 CPU 0 Unable to handle kernel paging request at virtual address 0000002c, epc == 803ab00c, ra == 803aafe0 Oops[#1]: CPU: 0 PID: 1 Comm: swapper Not tainted 6.4.0-rc3-00031-g84a9582fd203-dirty #57 $ 0: 00000000 10012c00 803aaeb0 00000000 $ 4: 80e12f60 80e12f50 80e12f58 81000030 $ 8: 00000000 805ff37c 00000000 33433538 $12: 65732030 00000006 80c2915d 6c616972 $16: 80e12f00 807b7630 00000000 00000000 $20: 00000004 00000348 000001a0 807623b8 $24: 00000018 00000000 $28: 80c24000 80c25d60 8078b148 803aafe0 Hi: 00000000 Lo: 00000000 epc: 803ab00c serial_base_ctrl_add+0x78/0xf4 ra: 803aafe0 serial_base_ctrl_add+0x4c/0xf4 Status: 10012c03KERNEL EXL IE Cause: 00000008 (ExcCode 02) BadVA: 0000002c PrId: 00000440 (R4400SC) Modules linked in: Process swapper (pid: 1, threadinfo=(ptrval), task=(ptrval), tls=00000000) Stack: 80760000 00000cc0 00400044 00400040 803aa02c 80d61ab8 00000000 807b7630 80760000 807623b8 807b7628 803aa644 80386998 00000000 80e17780 80220f68 80e17780 80d61ab8 80c17d80 80e17780 80e17780 8063c798 80e17780 80383fa0 00000010 80e17780 00000000 80386998…
Medium [CVE-2026-63927] Fix use after free in debug code
In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: Fix use after free in debug code We're not allowed to dereference "urb" after calling usb_hcd_giveback_urb() so save the urb->status ahead of time. A flaw was found in the Linux kernel, specifically within the `dwc2` USB driver. This vulnerability, known as a use-after-free, occurs when the system attempts to access memory that has already been released. This happens because a USB Request Block (urb) is incorrectly accessed after it has been returned. A local attacker could potentially exploit this issue to cause the system to crash (denial of service) or potentially gain unauthorized access or control. This vulnerability is rated as Moderate because successful exploitation requires local privileges and is restricted to systems utilizing DesignWare USB2 controller hardware, primarily resulting in a denial of service via a kernel crash. Typical Red Hat Enterprise Linux server and cloud deployments do not operate this specific USB hardware controller, significantly reducing real-world exposure. Furthermore, the vulnerable code is not present in Red Hat Enterprise Linux 7, 8, and 9, limiting potential impact to newer environments such as RHEL 10 and Red Hat In-Vehicle OS. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-825.
Medium [CVE-2026-63880] fix lock leak on ENOMEM in AMDGPU_GEM_OP_GET_MAPPING_INFO
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix lock leak on ENOMEM in AMDGPU_GEM_OP_GET_MAPPING_INFO The AMDGPU_GEM_OP_GET_MAPPING_INFO branch of amdgpu_gem_op_ioctl() holds three cleanup-tracked resources before calling kvcalloc(): the drm_gem_object reference from drm_gem_object_lookup(), the drm_exec lock on the looked-up GEM via drm_exec_lock_obj(), and the drm_exec lock on the per-process VM root page directory via amdgpu_vm_lock_pd(). All three are released by the out_exec label that every other error path in this function jumps to. The kvcalloc() failure path returns -ENOMEM directly, skipping out_exec and leaking all three. The leaked per-process VM root PD dma_resv lock is the load-bearing leak: any subsequent operation on the same VM (further GEM ops, command-submission, eviction, TTM shrinker callbacks) blocks on the held lock. DRM_IOCTL_AMDGPU_GEM_OP is DRM_AUTH | DRM_RENDER_ALLOW, so this is an unprivileged-local denial of service against the caller's GPU context, reachable by any process with /dev/dri/renderD* access. Route the failure through out_exec so drm_exec_fini() and drm_gem_object_put() run. Reproduced on stock 7.0.0-10, Ryzen 7 5700U / Radeon Vega (Lucienne): the failing ioctl returns -ENOMEM and a second GET_MAPPING_INFO on the same fd then blocks in drm_exec_lock_obj() on the leaked dma_resv.
Medium [CVE-2026-63948] fix chan ref leak in l2cap_chan_timeout on !conn
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix chan ref leak in l2cap_chan_timeout() on!conn __set_chan_timer() takes a l2cap_chan reference via l2cap_chan_hold() before scheduling the delayed work. The normal path in l2cap_chan_timeout() drops this reference with l2cap_chan_put() at the end, but the early return when chan->conn is NULL skips the put, leaking the reference. Add the missing l2cap_chan_put() before the early return. A flaw was found in the Linux kernel's Bluetooth Logical Link Control and Adaptation Protocol (L2CAP) component. When a channel's connection is null, an early exit path in the function fails to release a held channel reference. This oversight can lead to resource exhaustion over time, potentially causing system instability or a Denial of Service (DoS). This vulnerability is rated as having a Moderate impact because exploitation requires local access and is confined to denial of service through resource exhaustion, leaving system confidentiality and integrity intact. Typical enterprise deployments of Red Hat Enterprise Linux do not utilize Bluetooth devices or maintain active Bluetooth networking, which minimizes exposure under standard server configurations.
Medium [CVE-2026-63878] check num_entries in GEM_OP GET_MAPPING_INFO
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: check num_entries in GEM_OP GET_MAPPING_INFO kvcalloc(args->num_entries, sizeof(*vm_entries), GFP_KERNEL) at amdgpu_gem.c:1050 uses the user-supplied num_entries directly without any upper bounds check. Since num_entries is a __u32 and sizeof(drm_amdgpu_gem_vm_entry) is 32 bytes, a large num_entries produces an allocation exceeding INT_MAX, triggering WARNING in __kvmalloc_node_noprof(), causing a kernel WARNING, TAINT_WARN, and panic on CONFIG_PANIC_ON_WARN=y systems. Add a size bounds check before we invoke the kvzalloc() to reject oversized num_entries early with -EINVAL. (cherry picked from commit 1fe7bf5457f6efd7be60b17e23163ba54341d73d) A local attacker can exploit an integer overflow vulnerability by providing an excessively large value for the `num_entries` parameter in the `GEM_OP GET_MAPPING_INFO` ioctl. This can lead to an attempt to allocate an extremely large amount of memory, resulting in a kernel warning, system taint, and potentially a system panic, causing a Denial of Service (DoS). This vulnerability is rated as Moderate severity because exploitation is restricted to local authenticated users with access to AMD GPU device nodes and results strictly in a denial of service without compromising system confidentiality or integrity.
Medium [CVE-2026-63893] Reject u32 wrap in tb_property_entry_valid
In the Linux kernel, the following vulnerability has been resolved: thunderbolt: property: Reject u32 wrap in tb_property_entry_valid() entry->value is u32 and entry->length is u16; the sum is performed in u32 and wraps. A malicious XDomain peer can pick value = 0xffffff00, length = 0x100 so the sum 0x100000000 wraps to 0 and passes the > block_len check. tb_property_parse() then passes entry->value to parse_dwdata() as a dword offset into the property block, reading attacker-directed memory far past the allocation. For TEXT-typed entries with the "deviceid" or "vendorid" keys this lands in xd->device_name / xd->vendor_name and is readable back via the per-XDomain device_name / vendor_name sysfs attributes; the leak is NUL-bounded (kstrdup() stops at the first zero byte) and untargeted (the attacker picks a delta, not an absolute address). DATA-typed entries are parsed into property->value.data but not generically surfaced to userspace. Use check_add_overflow() so a wrapped sum is rejected. A remote attacker, by acting as a malicious XDomain peer, could craft a special property entry that causes an integer overflow when calculating memory access. This overflow allows the system to read memory outside of the intended buffer, leading to information disclosure through device name or vendor name system attributes. This vulnerability could expose sensitive, untargeted data.
Medium [CVE-2026-63937] Use READ_ONCE when reading entries/indices from PSC buffer
In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Use READ_ONCE() when reading entries/indices from PSC buffer Use READ_ONCE() when reading entries/indices from the guest-accessible Page State Change buffer to defend against TOCTOU bugs. Don't bother with READ_ONCE()/WRITE_ONCE() for cases where KVM is writing (and not consuming the result!), as the guest isn't supposed to touch the buffer while it's being processed. I.e. using READ_ONCE() is all about protecting against misbehaving guests. A flaw was found in the Linux kernel's Kernel-based Virtual Machine (KVM) with Secure Encrypted Virtualization (SEV). A misbehaving guest could exploit this timing issue by modifying the buffer after it has been checked but before it is used, potentially leading to an impact on the integrity of the virtualized environment. A TOCTOU race exists in the KVM/SEV SNP Page State Change handling path because KVM reads guest accessible PSC header indices and PSC entries without READ_ONCE(). A malicious guest can modify the PSC buffer while the host is validating and consuming it, which can make KVM process inconsistent entry data or index values during page state change handling. For the CVSS the PR:L is used because the attacker needs the ability to execute code in a guest or otherwise control a guest PSC buffer, but does not need host administrative privileges.
Medium [CVE-2026-63951] fix use-after-free in zram_writeback_endio
In the Linux kernel, the following vulnerability has been resolved: zram: fix use-after-free in zram_writeback_endio A crash was observed in zram_writeback_endio due to a NULL pointer dereference in wake_up. The root cause is a race condition between the bio completion handler (zram_writeback_endio) and the writeback task. In zram_writeback_endio, wake_up() is called on &wb_ctl->done_wait after releasing wb_ctl->done_lock. This creates a race window where the writeback task can see num_inflight become 0, return, and free wb_ctl before zram_writeback_endio calls wake_up(). By protecting wb_ctl with rcu_read_lock() in zram_writeback_endio and using kfree_rcu() to free it, we ensure that wb_ctl remains valid during the execution of zram_writeback_endio. A race condition exists in the zram_writeback_endio function, which handles writeback completions. This race condition can lead to a use-after-free vulnerability, causing a system crash and resulting in a Denial of Service (DoS). Red Hat severity: Moderate. Weakness: CWE-476. Red Hat lists Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9 as not affected.
Medium [CVE-2026-63903] validate interrupt status length
In the Linux kernel, the following vulnerability has been resolved: USB: serial: belkin_sa: validate interrupt status length The Belkin interrupt callback treats interrupt data as a four-byte status report and reads LSR/MSR fields at offsets 2 and 3. The interrupt-in buffer length is derived from endpoint wMaxPacketSize, and short interrupt transfers may complete successfully with a smaller actual_length. Check the completed interrupt packet length before parsing status fields so short interrupt endpoints and short successful packets are ignored instead of causing out-of-bounds or stale status-byte reads. KASAN report as below: BUG: KASAN: slab-out-of-bounds in belkin_sa_read_int_callback() Read of size 1 Call trace: belkin_sa_read_int_callback() (drivers/usb/serial/belkin_sa.c:202) __usb_hcd_giveback_urb() (drivers/usb/core/hcd.c:1630) dummy_timer() (?:?) The driver's interrupt handling routine fails to validate the length of incoming status reports. This oversight allows a local attacker, by connecting a specially crafted USB device, to trigger an out-of-bounds read. The primary consequence is a system crash, leading to a denial of service. This vulnerability is rated as having a Moderate impact for Red Hat Enterprise Linux because exploitation requires local access with the capability to attach a physical or emulated USB device.
Medium [CVE-2026-63954] fix a crash if hpfs_map_dnode_bitmap fails
In the Linux kernel, the following vulnerability has been resolved: hpfs: fix a crash if hpfs_map_dnode_bitmap fails If hpfs_map_dnode_bitmap fails, the code would call hpfs_brelse4 on uninitialized quad buffer head, causing a crash. A flaw was found in the Linux kernel's High Performance File System (HPFS) component. This vulnerability occurs when the hpfs_map_dnode_bitmap function fails, leading to the system attempting to release an uninitialized buffer. An attacker could potentially trigger this condition, resulting in a system crash and causing a Denial of Service (DoS). Red Hat severity: Moderate. Weakness: CWE-824. Red Hat lists Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9 as not affected.
Medium [CVE-2026-63961] validate count before reading Status Update VDO
In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmodes/displayport: validate count before reading Status Update VDO A broken/malicious device can send the incorrect count for a status update VDO, which will cause the kernel to read uninitialized stack data and send it off elsewhere. Fix this up by correctly verifying the count for the update object. A flaw was found in the Linux kernel's USB Type-C DisplayPort (DP) alternate mode. A malicious or improperly configured USB-C device can send a malformed status update Vendor Defined Object (VDO), which is a data structure used for communication. This vulnerability allows an attacker with physical access to a malicious USB-C device to potentially gain access to sensitive system information. This vulnerability is rated as having a Moderate impact because successful exploitation requires physical access to attach a malicious USB Type-C peripheral to the host. Systems deployed in physically secured server environments or virtualized guest instances lacking USB device passthrough are not exposed to this issue. Although an attacker with physical access could receive uninitialized kernel stack data over DisplayPort alternate mode communication, the issue does not allow code execution or data modification. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).
Medium [CVE-2026-63926] fix tail fragment offset in bpf_msg_push_data
In the Linux kernel, the following vulnerability has been resolved: bpf: sockmap: fix tail fragment offset in bpf_msg_push_data When bpf_msg_push_data() inserts data in the middle of a scatterlist entry, it splits the original entry into a left fragment and a right fragment. The right fragment offset is page-local, but the code advances it with `start`, which is the message-global insertion point. For inserts into a non-first SG entry, this over-advances the offset and leaves the split layout inconsistent. Advance the right fragment offset by the fragment-local delta, `start - offset`, which matches the length removed from the front of the original entry. When the `bpf_msg_push_data` function processes data, it incorrectly calculates the offset for data fragments, leading to an inconsistent memory arrangement. This issue could potentially allow a local attacker to cause data corruption or system instability. This vulnerability is rated as Moderate impact for Red Hat Enterprise Linux because exploitation is confined to local authenticated users and requires specific eBPF socket message programs to trigger a denial of service. Under typical enterprise deployments, standard unprivileged accounts cannot load or attach BPF programs to socket maps, restricting the attack surface to privileged or specialized networking workloads.
Medium [CVE-2026-63882] fix NULL pointer bug in svm_range_set_attr
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix NULL pointer bug in svm_range_set_attr The process_info could be NULL if user doesn't call kfd_ioctl_acquire_vm before calling kfd_ioctl_svm. (cherry picked from commit 83a26c812e0529eb040d31a76f73e33e637243d4) A flaw was found in the AMD KFD (Kernel Fusion Driver) component of the Linux kernel. This could lead to a denial of service. Systems lacking AMD graphics hardware or compute capabilities do not initialize the affected driver subsystem and are not exposed. In typical enterprise server deployments, unprivileged users do not have direct access to GPU device nodes, significantly restricting the practical attack surface. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-476. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9. Will not fix / out of support: Red Hat Enterprise Linux 6. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-64031] fix managed cache race for unaligned extents
In the Linux kernel, the following vulnerability has been resolved: erofs: fix managed cache race for unaligned extents After unaligned compressed extents were introduced, the following race could occur: [Thread 1] [Thread 2] (z_erofs_fill_bio_vec)... filemap_add_folio (1) (z_erofs_bind_cache).... folio_attach_private (2) filemap_add_folio (3) again Since (1) is executed but (2) hasn't been executed yet, it's possible that another thread finds the same managed folio in z_erofs_bind_cache() for a different pcluster and calls filemap_add_folio() again since folio->private is still Z_EROFS_PREALLOCATED_FOLIO. Fix this by explicitly clearing folio->private before making the folio visible in the managed cache so that another pcluster can simply wait on the locked managed folio as what we did for other shared cases [1]. This only impacts unaligned data compression (`-E48bit` with zstd, for example). [1] Commit 9e2f9d34dd12 ("erofs: handle overlapped pclusters out of crafted images properly") was originally introduced to handle crafted overlapped extents, but it addresses unaligned extents as well. A race condition exists when processing unaligned compressed extents, which can cause a managed memory page (folio) to be incorrectly added to the page cache multiple times.
Medium [CVE-2026-63998] call ethnl_ops_complete on module flash errors
In the Linux kernel, the following vulnerability has been resolved: ethtool: module: call ethnl_ops_complete() on module flash errors When validate() fails we are skipping over ethnl_ops_complete() even tho we already called ethnl_ops_begin(). When attempting to flash transceiver modules' firmware, a validation failure could cause the `ethnl_ops_complete()` function to be skipped. This oversight means that an operation initiated by `ethnl_ops_begin()` might not be properly concluded, potentially leading to unexpected behavior or resource management issues within the kernel. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-459. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel.
Medium [CVE-2026-63988] Fix sleep in atomic context in sysfs path
In the Linux kernel, the following vulnerability has been resolved: bridge: Fix sleep in atomic context in sysfs path Since the start of the git history, brport_store() always acquired the bridge lock. Back then this decision made sense: The bridge lock protects the STP state of the bridge and its ports and at that time the function was only used by two STP related attributes (cost and priority). Nowadays, brport_store() processes a lot more attributes and most of them do not need the bridge lock: * Bridge flags: Only require RTNL. Read locklessly by the data path. Annotations can be added in net-next. * FDB port flushing: Only requires the FDB lock. * Multicast attributes: Only require the multicast lock. * Group forward mask: Only requires RTNL. This is a problem as the bridge calls dev_set_promiscuity() when certain bridge port flags change and this function can sleep since the commit cited below, resulting in a splat such as [1]. Remove the now stale comment from br_switchdev_set_port_flag(). Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat package: kernel.
Medium [CVE-2026-63964] reject firmware images without a ':' record header
In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: ccg: reject firmware images without a ':' record header do_flash() locates the first.cyacd record with p = strnchr(fw->data, fw->size, ':'); while (p < eof) { s = strnchr(p + 1, eof - p - 1, ':');... } If the firmware image contains no ':' byte, strnchr() returns NULL. NULL compares less than the valid kernel pointer eof, so the loop body runs and strnchr() is called with p + 1 == (void *)1 and a length of roughly (unsigned long)eof, causing a wonderful crash. The not_signed_fw fallthrough earlier in do_flash() and the chip-state branches in ccg_fw_update_needed() allow an unsigned blob to reach this loop, so a root user who can place a crafted file under /lib/firmware and write the do_flash sysfs attribute can trigger the oops. Bail out with -EINVAL when the initial strnchr() returns NULL. A local attacker with root privileges can provide a specially crafted firmware image without a required record header. This malformed image can cause a null pointer dereference within the `do_flash()` function, leading to a kernel crash and a Denial of Service (DoS) on the system. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-476. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9.
Free weekly CVE digest
Every Monday: the week's critical and high advisories for Red Hat or every vendor, new CISA KEV entries and upcoming end-of-life dates.