Red Hat Linux Security Advisories & CVEs
12467 advisories tracked · Red Hat Security Data API · direct feeds checked every minute; rate-limited backstops use a safe source cadence
Android app · Google Play
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 — 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-72314] regulator_lock_two should test for EDEADLK not EDEADLOCK
In the Linux kernel, the following vulnerability has been resolved: regulator: core: regulator_lock_two() should test for EDEADLK not EDEADLOCK Compare against -EDEADLK, which is what ww_mutex_lock() actually returns and what every other deadlock check in this file already uses. Function regulator_lock_two() acquires two regulators via regulator_lock_nested() -> ww_mutex_lock(). On contention, ww_mutex_lock() returns -EDEADLK, which is the caller's signal to drop the lock it holds and retry the acquisition in the canonical order. However, regulator_lock_two() tests the return value against -EDEADLOCK rather than -EDEADLK. On most architectures, EDEADLK and EDEADLOCK are the same value, so the comparison happens to be correct and the bug is invisible. But on MIPS, SPARC, and PowerPC, those two errors have different values. The test is wrong: a genuine -EDEADLK backoff no longer matches -EDEADLOCK, so instead of unlocking and retrying, the code falls into WARN_ON(ret) and returns with only one of the two regulators locked. In practice, this is a bug only on MIPS, because the regulator core is not built or used on the other two platforms. In general, EDEADLK is preferred over EDEADLOCK for new code. The `regulator_lock_two()` function, responsible for acquiring two regulators, incorrectly checks for an error code (`EDEADLOCK`) instead of the correct one (`EDEADLK`).
Medium [CVE-2026-72426] Preserve pointer spill metadata during half-slot cleanup
In the Linux kernel, the following vulnerability has been resolved: bpf: Preserve pointer spill metadata during half-slot cleanup __clean_func_state() cleans dead stack slots in 4-byte halves. When the high half of a STACK_SPILL slot is dead and the low half remains live, cleanup converts the live low half to STACK_MISC or STACK_ZERO and clears the saved spilled_ptr metadata. That conversion is safe only for scalar spills. For a pointer spill, this metadata clear lets a later 32-bit fill from the still-live half avoid the normal non-scalar register-fill check and be treated as an ordinary scalar stack read. Leave non-scalar spill slots intact in this half-live shape. This is conservative for pruning and preserves the existing check_stack_read_fixed_off() rejection path for partial fills from pointer spills. A flaw was found in the Linux kernel's Berkeley Packet Filter (BPF) subsystem. The `__clean_func_state()` function, which manages stack slot cleanup, incorrectly clears metadata for pointer spills. This allows a subsequent read from a partially live stack slot to bypass crucial non-scalar register-fill checks, treating a pointer as a scalar value. This vulnerability could lead to a security bypass, potentially enabling information disclosure or other memory corruption issues.
Medium [CVE-2026-72420] avoid R5_Overlap races while breaking stripe batches
In the Linux kernel, the following vulnerability has been resolved: md/raid5: avoid R5_Overlap races while breaking stripe batches KCSAN report a race in break_stripe_batch_list() vs. raid5_make_request() on sh->dev[i].flags (plain word write vs. atomic bit op).. and.. one possible scenario is: CPU1 CPU2 break_stripe_batch_list(sh1) -> handle sh2 -> lock(sh2) -> sh2->batch_head = NULL -> unlock(sh2) -> test_and_clear_bit(R5_Overlap, sh2->dev[i].flags) -> wake_up_bit(sh2->dev[i].flags) raid5_make_request() -> add_all_stripe_bios(sh2) -> lock(sh2) -> stripe_bio_overlaps(sh2) returns true batch_head is NULL, so new bio overlap exist bio on sh2 -> true -> set_bit(R5_Overlap, sh2->dev[i].flags) -> unlock(sh2) -> wait_on_bit(sh2->dev[i].flags) -> sh2->dev[i].flags = sh1->dev[i].flags & ~R5_Overlap No wait_up_bit(), CPU2 could be wait_on_bit() forever... Fix by: - Expand the protect zone. - Use batch_head's device flag's snaphot when no held head_sh->stripe_lock. - Move sh/head_sh->batch_head = NULL to the end of protected zone, and, any concurrent add_all_stripe_bios() grabs sh->stripe_lock now either: - see batch_head!= null, and, is rejected by stripe_bio_overlaps() under the lock (no R5_Overlap wait ), or, - sees batch_head == NULL, only after dev[i].flags has already been set and the prior R5_Overlap waiters worken.
Medium [CVE-2026-72441] fix kernel-infoleak in dgram_recvmsg
In the Linux kernel, the following vulnerability has been resolved: ieee802154: fix kernel-infoleak in dgram_recvmsg() KMSAN reported a kernel-infoleak in move_addr_to_user(): BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:131 [inline] BUG: KMSAN: kernel-infoleak in _inline_copy_to_user include/linux/uaccess.h:205 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xcc/0x120 lib/usercopy.c:26 instrument_copy_to_user include/linux/instrumented.h:131 [inline] _inline_copy_to_user include/linux/uaccess.h:205 [inline] _copy_to_user+0xcc/0x120 lib/usercopy.c:26 copy_to_user include/linux/uaccess.h:236 [inline] move_addr_to_user+0x2e7/0x440 net/socket.c:302 ____sys_recvmsg+0x232/0x610 net/socket.c:2925... Uninit was stored to memory at: ieee802154_addr_to_sa include/net/ieee802154_netdev.h:369 [inline] dgram_recvmsg+0xa09/0xbe0 net/ieee802154/socket.c:739 The issue occurs because the `pan_id` field of `struct ieee802154_addr` is left uninitialized when the address mode is `IEEE802154_ADDR_NONE`. The execution flow is as follows: 1. `__ieee802154_rx_handle_packet()` declares a local `struct ieee802154_hdr hdr` on the stack. 2. `ieee802154_hdr_pull()` calls `ieee802154_hdr_get_addr()` to parse the source and destination addresses into this structure. 3.
Medium [CVE-2026-72460] check label build before no_new_privs test
In the Linux kernel, the following vulnerability has been resolved: apparmor: check label build before no_new_privs test aa_change_profile() builds a replacement label with fn_label_build_in_scope() before the no_new_privs subset check. The build helper can fail and return NULL or an ERR_PTR, but the result was passed to aa_label_is_unconfined_subset() before the existing IS_ERR_OR_NULL() check. Reuse the existing target-label build failure handling immediately after the build. This preserves the current audit handling while preventing the subset helper from dereferencing an invalid label. A flaw was found in the Linux kernel's AppArmor security module. When changing a security profile, the `aa_change_profile()` function might attempt to use an invalid security label before properly checking if the label was successfully created. This oversight could allow a local attacker to trigger a system crash by causing the kernel to access an invalid memory location, leading to a Denial of Service (DoS). In aa_change_profile(), the replacement label built by fn_label_build_in_scope() was passed to aa_label_is_unconfined_subset() before the existing IS_ERR_OR_NULL() validation, so a failed label build could result in the kernel dereferencing an invalid (NULL or error) label.
Medium [CVE-2026-72214] Fix missing nvmem_device_put causing reference leak
In the Linux kernel, the following vulnerability has been resolved: power: supply: cpcap-battery: Fix missing nvmem_device_put() causing reference leak In cpcap_battery_detect_battery_type(), the reference to an nvmem device obtained via nvmem_device_find() is not released with nvmem_device_put() on the success or read-failure paths, causing a permanent reference leak. The driver’s retry logic on subsequent battery property reads can compound this leak, preventing the nvmem device from ever being freed. Found by code review. This vulnerability occurs because a reference to a non-volatile memory (nvmem) device is not properly released after being acquired. Repeated attempts to read battery properties can exacerbate this issue, leading to a permanent memory leak. This can ultimately result in resource exhaustion, potentially causing system instability or a denial of service. No Red Hat products are affected by this flaw: the vulnerable cpcap-battery driver code is not present in the Red Hat Enterprise Linux (including kernel-rt) and Red Hat In-Vehicle OS kernels shipped for the covered product streams, so exploitation is not possible on Red Hat offerings. 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-772.
Medium [CVE-2026-72210] fix off-by-one in mapping pairs decoding bounds checks
In the Linux kernel, the following vulnerability has been resolved: ntfs: fix off-by-one in mapping pairs decoding bounds checks In ntfs_mapping_pairs_decompress(), attr_end points one byte past the end of the attribute record: attr_end = (u8 *)attr + le32_to_cpu(attr->length); The two bounds checks validating that mapping pair data bytes fit within the attribute use strict greater-than (>), which allows a one-byte out-of-bounds read when the data extends exactly to attr_end: b = *buf & 0xf; if (b) { if (unlikely(buf + b > attr_end)) // off-by-one goto io_error; for (deltaxcn = (s8)buf[b--]; b; b--) deltaxcn = (deltaxcn << 8) + buf[b]; } When buf + b == attr_end, the check evaluates to false and buf[b] reads one byte past the valid attribute boundary. The same pattern appears in the LCN delta bytes check. A flaw was found in the Linux kernel's NTFS filesystem driver. An error in how the driver checks the boundaries of data it processes, specifically an 'off-by-one' error, allows it to read one byte beyond its intended memory region. This 'out-of-bounds read' could potentially lead to the disclosure of sensitive information from the kernel's memory. 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-125.
Medium [CVE-2026-72200] detect mapping-pairs LCN accumulator overflow
In the Linux kernel, the following vulnerability has been resolved: ntfs: detect mapping-pairs LCN accumulator overflow The NTFS mapping-pairs parser accumulates relative LCN deltas in a signed integer. A corrupted attribute can drive that addition past the representable range. One corrupt runlist shape sets the accumulated LCN to S64_MAX and then adds a delta of 1 in the next mapping-pairs entry. Signed overflow is undefined and can turn an invalid runlist into a different set of physical clusters. Check the LCN addition for overflow before storing the next run. A corrupted attribute can cause a signed integer overflow when processing Logical Cluster Number (LCN) deltas. This overflow leads to undefined behavior, which may result in the system incorrectly interpreting file system structures. This could potentially lead to data corruption or unauthorized data access. A flaw in the Linux kernel's NTFS mapping-pairs parser was rated by Red Hat Product Security as having moderate impact. As a consequence, the kernel may interpret an invalid runlist as a different set of physical clusters, potentially leading to data corruption on the mounted filesystem.
Medium [CVE-2026-72359] fix NPD in bo_meminfo
In the Linux kernel, the following vulnerability has been resolved: drm/xe: fix NPD in bo_meminfo() When a buffer object is purged, its ttm.resource is set to NULL via the TTM pipeline gutting flow. However, the BO remains in the client's object list until userspace explicitly closes the GEM handle. If memory stats are queried during this time, accessing bo->ttm.resource->mem_type will result in a NULL pointer dereference. Fix this by safely skipping purged BOs in bo_meminfo, as they no longer consume any memory. User is getting NPD on device resume, and possible theory is that in bo_move(), if we need to evict something to SYSTEM to save the CCS state, but the BO is marked as dontneed, this won't trigger a move but will nuke the pages, leaving us with a NULL bo resource. And the meminfo() doesn't look ready to handle a NULL resource. v2 (Sashiko): - There could potentially be other cases where we might end up with a NULL resource, so make this a general NULL check for now. (cherry picked from commit c9a8e7daa0afe3161111e27fd92176e608c7f186) A flaw was found in the Linux kernel's `drm/xe` graphics driver. A local user could trigger a NULL pointer dereference when querying memory statistics for a buffer object that has been purged.
Medium [CVE-2026-72233] reacquire gw address after skb realloc
In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: reacquire gw address after skb realloc The pskb_may_pull() called by batadv_bla_is_backbone_gw() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This vulnerability occurs when a buffer is reallocated, but existing pointers are not updated, leading to a use-after-free condition. A local attacker could potentially exploit this to cause a system crash (denial of service) or, in some cases, execute arbitrary code with elevated privileges. 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. 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-72232] ensure minimal ethernet header on TX
In the Linux kernel, the following vulnerability has been resolved: batman-adv: ensure minimal ethernet header on TX As documented in commit 8bd67ebb50c0 ("net: bridge: xmit: make sure we have at least eth header len bytes"), it is possible by for a local user with eBPF TC hook access to attach a tc filter which truncates the packet and redirects to an batadv interface. But the code assumes that at least ETH_HLEN bytes are available and thus might read outside of the available buffer. The batadv_interface_tx() must therefore always check itself if enough data is available for the ethernet header and don't rely on min_header_len. The `batadv_interface_tx()` function then attempts to read beyond the allocated buffer for the Ethernet header, potentially leading to an out-of-bounds read. This could result in information disclosure or a denial of service. 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-125. 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-72226] prevent TVLV OOB check overflow
In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: prevent TVLV OOB check overflow A TT unicast TVLV contains the number of VLANs stored in it. This number is an u16 and gets multiplied by the size of the struct batadv_tvlv_tt_vlan_data (8 bytes). The size can therefore overflow the u16 used to store the tt_vlan_len. All additional safety checks to prevent out-of-bounds access of the TVLV buffer are invalid due to this overflow. Using size_t prevents this overflow and ensures that the safety checks compare against the actual buffer requirements. A flaw was found in the Linux kernel's batman-adv (Better Approach To Mobile Ad-hoc Networking - Advanced) module. An integer overflow can occur when calculating the length of a Translation Table Type-Length-Value (TVLV) unicast message. This vulnerability could result in memory corruption. 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-787. 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-72276] fix potential memory leak in metronomefb_probe
In the Linux kernel, the following vulnerability has been resolved: fbdev: metronomefb: fix potential memory leak in metronomefb_probe() The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup(). A flaw was found in the `metronomefb` framebuffer driver within the Linux kernel. This vulnerability occurs because memory allocated for page references is not properly released when an error occurs during initialization. A local attacker could potentially exploit this to cause a denial of service due to excessive memory consumption. Red Hat rates the impact of this flaw as Low because exploitation requires local access and the ability to reach the driver's initialization error path, and the consequence is limited to memory exhaustion. All currently tracked Red Hat Enterprise Linux and Red Hat In-Vehicle OS kernel, kernel-rt, and related streams are marked not affected for this flaw because the vulnerable code is not present in the shipped kernels. 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-772.
Medium [CVE-2026-72206] validate index block header more strictly
In the Linux kernel, the following vulnerability has been resolved: ntfs: validate index block header more strictly Modify ntfs_index_block_inconsisent() to perform stricter validation of INDEX_HEADER geometry in INDX blocks, and update ntfs_lookup_inode_by_name() to use that function to validate INDX blocks. A flaw was found in the Linux kernel's NTFS filesystem driver. Insufficient validation of index block headers within INDX blocks could allow a local attacker to craft a malicious NTFS filesystem image. When this image is processed by the kernel, it could lead to a kernel panic due to an out-of-bounds read, resulting in a denial of service (DoS). 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-1288. 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-72154] Fix jump_label smp syncing
In the Linux kernel, the following vulnerability has been resolved: openrisc: Fix jump_label smp syncing The original commit 8c30b0018f9d ("openrisc: Add jump label support") copies from arm64 and does not properly consider how icache invalidation on remote cores works in OpenRISC. On OpenRISC remote icaches need to be invalidated otherwise static key's may remain state after updating. Properly invalidate remote core icaches on SMP systems by using icache_all_inv. The old code uses kick_all_cpus_sync() which runs a no-op IPI function call on remote CPU's which does execute a lot of code and flushes many cache lines in the process, but does not flush all and it's not correct on OpenRISC. 2. For architectures that do not have WRITETHROUGH caches be sure to flush the dcache after patching. To test this I first reproduced the issue using a custom test module [0]. The test confirmed that some icache lines maintained stale static_key code sequences after calling static_branch_enable(). After this patch there are no longer jump_label coherency issues. [0] A flaw was found in the Linux kernel, specifically within the OpenRISC architecture's handling of jump label synchronization in Symmetric Multiprocessing (SMP) systems. The implementation did not correctly invalidate instruction caches (icaches) on remote processor cores after updates.
Medium [CVE-2026-72176] put stats for scheme_add_dirs internal error
In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs-schemes: put stats for scheme_add_dirs() internal error damon_sysfs_scheme_add_dirs() setup the tried_regions directory after the stats directory setup is completed. When the tried_regions directory setup is failed, the setup function ensures the reference for the tried regions directory is released. Hence the error path should put references on setup succeeded directory objects, starting from the stats directory. However, the error path is putting the tried_regions directory instead of the stats directory. As a direct result, the stats directory object is leaked. Worse yet, if the tried_regions directory setup failed from the initial allocation, the scheme->tried_regions field remains uninitialized. The following kobject_put(&scheme->tried_regions->kobj) call in the error path will dereference the uninitialized memory. The setup failures should not be common. But once it happens, the consequence is quite bad. The issue was discovered [1] by Sashiko. A flaw was found in the Linux kernel's mm/damon/sysfs-schemes component, which could lead to a denial of service or system instability. This vulnerability is caused by an incorrect error handling path in the damon_sysfs_scheme_add_dirs() function, resulting in a resource leak and the dereference of uninitialized memory.
Medium [CVE-2026-72293] Add missing radix_tree_preload in _gaccess_shadow_fault
In the Linux kernel, the following vulnerability has been resolved: KVM: s390: vsie: Add missing radix_tree_preload() in _gaccess_shadow_fault() Add missing radix_tree_preload() in _gaccess_shadow_fault() to guarantee forward progress. The core of _gaccess_shadow_fault() has been split into ___gaccess_shadow_fault() in order to simplify locking. A flaw was found in the kernel's KVM (Kernel-based Virtual Machine) s390 vsie component. A missing `radix_tree_preload()` call in the `_gaccess_shadow_fault()` function can prevent the system from guaranteeing forward progress. This could lead to system instability or a Denial of Service (DoS), where the system becomes unresponsive. On an affected kernel, a local attacker able to run a nested virtualization guest could use this flaw to make the system unresponsive, resulting in a denial of service. The vulnerable code was introduced in the upstream kernel in version 7.0 and is not present in the Red Hat Enterprise Linux and Red Hat In-Vehicle OS kernels currently in support; all currently tracked kernel and kernel-rt packages are therefore not affected by this issue. 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-909.
Medium [CVE-2026-72397] (pmbus/core) honor vrm_version in pmbus_data2reg_vid
In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus/core) honor vrm_version in pmbus_data2reg_vid() pmbus_data2reg_vid() hardcoded the VR11 encoding regardless of the vrm_version configured by the driver, while pmbus_reg2data_vid() already switched on it. Any driver that selects a non-VR11 VID mode and exposes a regulator (or hwmon vout setter) sent dangerously wrong codes to PMBUS_VOUT_COMMAND -- e.g. an nvidia195mv part asked for 200 mV got the VR11 clamp to 500 mV encoded as 0xB2, which the chip interprets as 1080 mV. Mirror pmbus_reg2data_vid() so writes round-trip with reads. A flaw was found in the Linux kernel's `hwmon` subsystem, specifically within the `pmbus/core` module. This issue could lead to drivers sending dangerously wrong voltage codes to the Power Management Bus (PMBus) `VOUT_COMMAND`, potentially causing hardware instability or damage due to incorrect voltage regulation. The pmbus_data2reg_vid() function hardcoded the VR11 VID encoding when converting a requested voltage into a PMBUS_VOUT_COMMAND register value, ignoring the vrm_version configured by the driver, even though the corresponding read path pmbus_reg2data_vid() already honored it. The flaw is not network-reachable and requires local privileged access to the exposed voltage-setting interface.
Medium [CVE-2026-72316] dm era: fix NULL pointer dereference in metadata_open
In the Linux kernel, the following vulnerability has been resolved: dm era: fix NULL pointer dereference in metadata_open() metadata_open() returns NULL when kzalloc_obj() fails, but the caller era_ctr() only checks IS_ERR(md). Since IS_ERR(NULL) returns false, the NULL pointer is treated as a valid result and later assigned to era->md, leading to a NULL pointer dereference when the metadata is accessed. Fix this by returning ERR_PTR(-ENOMEM) on allocation failure, consistent with dm-cache-metadata.c, dm-thin-metadata.c, and dm-clone-metadata.c which all use ERR_PTR(-ENOMEM) for the same pattern. A flaw was found in the Linux kernel's device mapper (dm) era target. The calling function, `era_ctr()`, does not correctly validate this return, leading to a NULL pointer dereference when the metadata is accessed. This issue can be triggered by a local attacker, potentially causing a system crash and resulting in a Denial of Service (DoS). Red Hat severity: Low — CVSS 4.7 (CVSS:3.1/AV:L/AC:H/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 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-72225] fix integer underflow in jbd2_journal_initialize_fast_commit
In the Linux kernel, the following vulnerability has been resolved: jbd2: fix integer underflow in jbd2_journal_initialize_fast_commit() jbd2_journal_initialize_fast_commit() validates journal capacity by checking (journal->j_last - num_fc_blks < JBD2_MIN_JOURNAL_BLOCKS). Both j_last and num_fc_blks are unsigned, so when num_fc_blks exceeds j_last the subtraction wraps to a large value, bypassing the bounds check. The resulting underflow corrupts j_last, j_fc_first, and j_free, leading to journal abort. Fix by checking num_fc_blks against j_last before the subtraction, returning -EFSCORRUPTED. A flaw was found in the Linux kernel's jbd2 journaling layer. This issue can result in a Denial of Service (DoS) for the affected 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-191. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; 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.