Red Hat Linux Security Advisories & CVEs
12973 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-72457] fail policy unpack on accept2 allocation failure
In the Linux kernel, the following vulnerability has been resolved: apparmor: fail policy unpack on accept2 allocation failure unpack_pdb() may need to allocate a missing ACCEPT2 table for older policy data. If that allocation failed, it set an error message but jumped to the success path, returning a policydb with the required table missing. Return -ENOMEM through the normal failure path when the ACCEPT2 allocation fails. Remove the now-unused out label. A flaw was found in the AppArmor security module within the Linux kernel. During the unpacking of security policies, a memory allocation failure for the `ACCEPT2` table was not handled correctly. This could result in an incomplete security policy being loaded, potentially leading to a bypass of intended security restrictions or unexpected system behavior. Red Hat rates the impact of this flaw as moderate (CVSS 5.5, CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Exploitation requires local access, privileged policy-loading capability, and a memory allocation failure occurring during policy unpacking. All tracked Red Hat Enterprise Linux and Red Hat In-Vehicle OS streams are marked NOT affected for this flaw because the vulnerable code is not present in the shipped kernels. Weakness: CWE-252.
Medium [CVE-2026-72195] bound attr_off in UpdateResidentValue against data_off
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound attr_off in UpdateResidentValue against data_off In do_action()'s UpdateResidentValue case (fslog.c:3307), lrh->attr_off and lrh->redo_len come from the on-disk LRH. When they satisfy aoff + dlen res.data_off, the assignment attr->res.data_size = cpu_to_le32(aoff + dlen - data_off); underflows to ~4 GiB (e.g. 0xFFFFFFF9 when aoff=0x10, dlen=1, data_off=0x18). Subsequent code that reads attr->res.data_size to walk the resident attribute payload would then read up to 4 GiB past the 1024-byte MFT record allocation. The existing mi_enum_attr() defense in fs/ntfs3/record.c:287 catches the corrupted data_size on the next attribute walk and fails the mount, but only on the path that walks all attributes. A read site that picks an attribute by name and reads its data_size without re-validating is not covered. Validate aoff against data_off and asize at the source. A flaw was found in the Linux kernel's ntfs3 file system driver. An integer underflow vulnerability occurs in the UpdateResidentValue function when processing a maliciously crafted Log Record Header (LRH). This underflow can lead to an incorrect calculation of data_size, allowing subsequent operations to read up to 4 Gigabytes (GiB) of memory beyond the intended buffer. This out-of-bounds read could result in information disclosure.
Medium [CVE-2026-72386] Fix a leak when a group is evicted before the tiler OOM is serviced
In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix a leak when a group is evicted before the tiler OOM is serviced A group ref is tied to the pending tiler_oom_work, so we need to release it if the cancel was effective. This vulnerability occurs when a group is evicted before the tiler Out-Of-Memory (OOM) service can process it, leading to a resource leak. An attacker could potentially exploit this to cause resource exhaustion, resulting in a Denial of Service (DoS). When a GPU group is evicted while its tiler out-of-memory (OOM) handling work is still pending, the group reference held by that pending work is not released, resulting in a kernel reference leak. A local attacker with access to the Panthor DRM device could repeatedly trigger tiler OOM events combined with group eviction to accumulate leaked references and exhaust kernel resources, resulting in a denial of service. The Red Hat CVSS 3.1 base score for this flaw is 5.5 (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H); however, Red Hat rates the overall impact as Low because exploiting it requires local access to the affected GPU device and the consequence is limited to availability loss through resource exhaustion, with no impact on confidentiality or integrity.
Medium [CVE-2026-72439] fix writes_pending leak on write request failures
In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix writes_pending leak on write request failures raid10_make_request() acquires a writes_pending reference with md_write_start() before dispatching write requests. Several failure paths in raid10_write_request() complete the bio and return without reaching the normal write completion path, causing the corresponding md_write_end() to be skipped. Make raid10_write_request() return a status indicating whether the write request was successfully queued. When write requests fail, the raid10_write_request() function may not properly release a writes_pending reference. This resource leak can accumulate over time, potentially leading to a denial of service (DoS) condition where the system becomes unresponsive or crashes. Each such failed write request leaks a writes_pending reference, leaving the RAID10 array with a permanently elevated pending-write count; later operations that wait for writes to drain, such as array management or recovery operations, may then hang, resulting in a local denial of service. Exploitation requires local write access to a filesystem or block device backed by an affected RAID10 array and a code path in which a write request fails.
Medium [CVE-2026-72401] Fix insn_aux_data leak on verifier err_free_env path
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix insn_aux_data leak on verifier err_free_env path When bpf_check() allocates env->insn_aux_data successfully but later fails to allocate env->succ, it jumps directly to err_free_env. The existing vfree(env->insn_aux_data) sits before the err_free_env label, so that direct jump bypasses it and leaks insn_aux_data. Move vfree(env->insn_aux_data) into err_free_env so all early and late exit paths release it consistently. A flaw was found in the Linux kernel's Berkeley Packet Filter (BPF) verifier. This vulnerability occurs when the bpf_check() function fails to allocate certain resources, leading to a memory leak of insn_aux_data. An attacker could potentially exploit this by repeatedly triggering the flaw, which may exhaust system memory and result in a Denial of Service (DoS). Red Hat Enterprise Linux 6, 7, 8, and 9, and the rhel-10.0.z and rhel-10.2.z streams, are not affected because the change that introduced this flaw is not present in those kernels. For the affected streams, the fix is currently deferred because this is a low-severity resource leak on an error-handling path that only manifests when a kernel memory allocation fails; the residual risk is a local denial of service through gradual memory exhaustion.
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.