Red Hat Linux Security Advisories & CVEs
12974 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-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.
Medium [CVE-2026-72321] Fix potential memory leaks in igmp_mod_timer and igmp_stop_timer
In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: Fix potential memory leaks in igmp_mod_timer() and igmp_stop_timer() When a timer is deleted and not re-armed in igmp_mod_timer(), or stopped in igmp_stop_timer(), the code currently decrements the reference counter of the multicast list entry @im using refcount_dec(&im->refcnt). However, both functions can be called from the RCU reader path: - igmp_mod_timer() via igmp_heard_query() -> for_each_pmc_rcu() - igmp_stop_timer() via igmp_rcv() -> igmp_heard_report() If the group im was concurrently removed from the list by ip_mc_dec_group(), its reference count might have already been decremented to 1. In this case, timer_delete() succeeds, and refcount_dec() decrements the refcount from 1 to 0. Since refcount_dec() does not free the object when it hits 0 (unlike ip_ma_put()), the im structure is leaked. Fix this by using ip_ma_put(im) instead of refcount_dec(&im->refcnt), and deferring the put until after the spinlock is released. A flaw was found in the Linux kernel's IPv4 Internet Group Management Protocol (IGMP) component. Incorrect handling of reference counts in the `igmp_mod_timer()` and `igmp_stop_timer()` functions can occur when a multicast list entry is concurrently removed. This can lead to a memory leak of the `im` structure, potentially impacting system stability.
Medium [CVE-2026-72295] Validate irqchip index in irqfd routing
In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Validate irqchip index in irqfd routing Sashiko reported that the irqchip index is not validated for LoongArch. Add validation and reject out-of-range irqchip indexes to avoid indexing past the routing table's chip array. A flaw was found in the Linux kernel's Kernel-based Virtual Machine (KVM) for LoongArch architecture. An unvalidated interrupt controller (irqchip) index in the irqfd routing mechanism could allow a local attacker to perform an out-of-bounds memory access. This could lead to a denial of service or potentially privilege escalation within the system. 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-823. 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-72331] Fix VMA access race
In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Fix VMA access race aie2_populate_range() and amdxdna_umap_release() access a saved VMA pointer that may have already been freed, leading to a potential use-after-free. Remove the VMA accesses from these functions to avoid the race. This race condition can lead to a use-after-free vulnerability, which could result in system instability or potentially allow a local attacker to escalate privileges. A local user with access to an affected device could potentially trigger this use-after-free, causing system instability or a kernel crash. Red Hat assessed this flaw as having moderate impact (CVSS 5.5, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), limited to availability, whereas the upstream CVE record assigns a higher score (7.8) that assumes full confidentiality, integrity, and availability impact. The vulnerable code is not present in the Red Hat Enterprise Linux and Red Hat In-Vehicle OS kernels shipped by Red Hat, so all Red Hat products are currently marked as not affected. Weakness: CWE-825.
Medium [CVE-2026-72395] (pmbus) Fix passing events to regulator core
In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus) Fix passing events to regulator core Sashiko reports: Commit 754bd2b4a084 ("hwmon: (pmbus/core) Protect regulator operations with mutex") introduced a worker to batch regulator events over time using atomic_or(). The delayed worker then passes the combined bitmask unmodified to regulator_notifier_call_chain(). The core regulator subsystem's regulator_handle_critical() function evaluates the event parameter using a strict switch statement. If multiple distinct faults occur before the worker runs (e.g., REGULATOR_EVENT_UNDER_VOLTAGE | REGULATOR_EVENT_OVER_CURRENT), the combined bitmask fails to match any case. This leaves the reason as NULL and completely bypasses the critical hw_protection_trigger(). Fix the problem by passing events bit by bit to the regulator event handler. A worker designed to batch regulator events can combine multiple distinct hardware fault events into a single bitmask. This combined bitmask is then incorrectly processed by the critical hardware protection function, `regulator_handle_critical()`, causing it to bypass essential safety mechanisms. This could prevent the system from properly responding to critical hardware faults, potentially leading to system instability or damage. A moderate-impact flaw was found in the Linux kernel hwmon (pmbus) subsystem.
Medium [CVE-2026-72334] fix malformed ISO_END/CONT handling
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: fix malformed ISO_END/CONT handling Core specification (Part C vol 4 sec 5.4.5) does not exclude empty ISO_CONT, ISO_END packets. We currently reject them if they are last. If controller sends malformed sequence ISO_START -> rx_len = 4, ISO_CONT skb->len 4, ISO_START that ends payload in ISO_CONT, we leak conn->rx_skb. If controller sends too long ISO_END, we panic on skb_put. Fix by marking unfinished ISO_START via conn->rx_skb!= NULL. Check skb->len properly before skb_put. Combine the ISO_CONT/END code paths as they require the same initial checks. Reject too short ISO_END packets. A remote attacker, by sending specially crafted malformed Bluetooth ISO packets, could trigger a kernel panic, leading to a denial of service. Additionally, this vulnerability could result in a memory leak within the kernel. This issue arises from improper handling of ISO_END and ISO_CONT packets, particularly when they are malformed or unexpected. 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. 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-rt.
Medium [CVE-2026-72230] free unfragmentable packet
In the Linux kernel, the following vulnerability has been resolved: batman-adv: frag: free unfragmentable packet The caller of batadv_frag_send_packet() assume that the skb provided to the function are always consumed. But the pre-check for an empty payload or the zero fragment size returned an error without any further actions. A failed pre-check must use the same error handling code as the rest of the function. A flaw was found in the `batman-adv` (Better Approach To Mobile Ad-hoc Networking - Advanced) fragmentation module of the Linux kernel. The `batadv_frag_send_packet()` function, responsible for sending fragmented packets, does not properly free allocated memory when a packet is deemed unfragmentable due to an empty payload or zero fragment size. This oversight can lead to a memory leak, potentially affecting system stability and performance. When batadv_frag_send_packet() rejected a packet as unfragmentable because of an empty payload or a zero fragment size, it returned an error without freeing the associated socket buffer (skb), even though callers of the function assume the skb is always consumed. Red Hat rated this flaw Moderate (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), affecting only availability, because exploiting it requires the ability to locally originate the malformed batman-adv traffic that reaches the flawed error path.
Medium [CVE-2026-72360] Don't attempt to process FAST_REQ or EVENT relays
In the Linux kernel, the following vulnerability has been resolved: drm/xe/pf: Don't attempt to process FAST_REQ or EVENT relays Currently defined VF/PF relay actions use regular REQUEST messages only and the PF shouldn't attempt to handle FAST_REQUEST nor EVENT messages as this would result in breaking the VFPF ABI protocol and also might trigger an assert on the PF side. (cherry picked from commit 1714d360fc5ae2e0886a69e979095d9c7ff3568a) The Physical Function (PF) incorrectly attempts to process `FAST_REQUEST` or `EVENT` messages, which are not part of the defined Virtual Function to Physical Function (VFPF) Application Binary Interface (ABI) protocol. This misprocessing can lead to a violation of the VFPF ABI protocol and may trigger an assert on the PF side, potentially resulting in a denial of service. A denial-of-service flaw rated moderate by Red Hat was found in the Linux kernel's drm/xe SR-IOV GuC relay handling for Intel Xe graphics. No impact on confidentiality or integrity has been identified. The Red Hat Enterprise Linux 9 and 10 kernel and kernel-rt components and the Red Hat In-Vehicle OS 2 kernels are affected; because the impact is limited to denial of service by an attacker who already controls a VF on an affected host, the fix has been deferred to a future update, leaving that residual risk in the meantime.
Medium [CVE-2026-72149] Fix burst size calculation
In the Linux kernel, the following vulnerability has been resolved: dmaengine: tegra: Fix burst size calculation Currently, the Tegra GPC DMA hardware requires the transfer length to be a multiple of the max burst size configured for the channel. When a client requests a transfer where the length is not evenly divisible by the configured max burst size, the DMA hangs with partial burst at the end. Fix this by reducing the burst size to the largest power-of-2 value that evenly divides the transfer length. For example, a 40-byte transfer with a 16-byte max burst will now use an 8-byte burst (40 / 8 = 5 complete bursts) instead of causing a hang. This issue was observed with the PL011 UART driver where TX DMA transfers of arbitrary lengths were stuck. 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-131. 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-rt.
Medium [CVE-2026-72294] Check irq validity in kvm_vcpu_ioctl_interrupt
In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Check irq validity in kvm_vcpu_ioctl_interrupt() Function kvm_vcpu_ioctl_interrupt() can be called from userspace, here add irq validility cheking in kvm_vcpu_ioctl_interrupt(). A flaw was found in the Linux kernel's Kernel-based Virtual Machine (KVM) component, specifically within the LoongArch architecture. The `kvm_vcpu_ioctl_interrupt()` function, which can be invoked from userspace, lacks proper validation of interrupt requests. This missing validity check could allow a local attacker to trigger an invalid interrupt, potentially leading to a denial of service. Red Hat rated this flaw Moderate (CVSS 3.1 score 5.5, CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) because the impact is limited to availability, with no confidentiality or integrity impact; this differs from the upstream CVEORG rating of Important (8.8), which assumes a changed scope with high confidentiality and integrity impact. Red Hat Enterprise Linux and Red Hat In-Vehicle OS are not affected by this flaw because the vulnerable LoongArch KVM code is not present in the kernels shipped for these products. Weakness: CWE-1287.
Medium [CVE-2026-72159] reject non-inline dinodes with i_size and zero i_clusters
In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject non-inline dinodes with i_size and zero i_clusters On a volume mounted without OCFS2_FEATURE_INCOMPAT_SPARSE_ALLOC, a non-inline regular file with non-zero i_size and zero i_clusters is structurally malformed: the extent map declares no allocated clusters yet the size header claims content exists. Keep rejecting that shape, but express it through a shared predicate so the same invariant is available to normal inode reads and online filecheck. The same zero-cluster shape is also malformed for non-inline directories. ocfs2 directory growth allocates backing storage before advancing i_size, and ocfs2_dir_foreach_blk_el() later walks until ctx->pos reaches i_size_read(inode). A forged directory dinode with a huge i_size and no clusters would repeatedly fail on holes while advancing through the claimed size. Sparse regular files remain exempt: on sparse-alloc volumes, truncate can legitimately grow i_size without allocating clusters. System inodes and inline-data dinodes also retain their separate storage rules. Mirror the check in ocfs2_filecheck_validate_inode_block() as well. filecheck reports through its own error namespace, so malformed size/cluster state is logged as a filecheck invalid-inode result rather than via ocfs2_error(), but it must not proceed into ocfs2_populate_inode().
Medium [CVE-2026-72265] fix potential memory leak in nvidiafb_probe
In the Linux kernel, the following vulnerability has been resolved: fbdev: nvidia: fix potential memory leak in nvidiafb_probe() In nvidiafb_probe(), the memory allocated for modelist in nvidia_set_fbinfo() is not freed in the subsequent error paths. Fix that by calling fb_destroy_modelist(). A flaw was found in the Linux kernel's NVIDIA framebuffer driver. During the initialization process within the `nvidiafb_probe()` function, if certain error conditions occur, memory allocated for internal data structures is not properly released. This can lead to a memory leak, potentially affecting system stability and performance over extended periods. When nvidiafb_probe() fails on an error path after nvidia_set_fbinfo() has allocated the framebuffer mode list, that memory is not released, resulting in a small kernel memory leak per failed probe attempt. Triggering the flaw requires local access with privileges sufficient to influence driver loading, device binding, or PCI framebuffer probe conditions, and the consequence is limited to memory exhaustion (denial of service) after repeated failed probes; confidentiality and integrity are not affected. Affected products named by the advisory: Red Hat Enterprise Linux 8; Red Hat package: kernel-rt.
Medium [CVE-2026-72471] prevent potential lcn remains uninitialized
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: prevent potential lcn remains uninitialized The target VCN being sought was not found within runs[0], causing run_lookup() to return false. This causes run_lookup_entry() to return false, which in turn results in a len value of 0, and the new parameter passed to attr_data_get_block() is NULL. Collectively, these factors ultimately cause attr_data_get_block_locked() to exit prematurely without initializing lcn, thereby triggering [1]. To prevent [1], the clen check within ni_seek_data_or_hole() has been moved to occur before the lcn check. [1] BUG: KMSAN: uninit-value in ni_seek_data_or_hole+0x24f/0x5f0 fs/ntfs3/frecord.c:2862 ni_seek_data_or_hole+0x24f/0x5f0 fs/ntfs3/frecord.c:2862 ntfs_llseek+0x22a/0x4a0 fs/ntfs3/file.c:1530 vfs_llseek fs/read_write.c:391 [inline] An uninitialized value vulnerability exists when processing NTFS3 filesystem operations. This can lead to a kernel crash, resulting in a denial of service (DoS) for the affected system. A local attacker could potentially exploit this by interacting with a specially crafted NTFS3 filesystem. A moderate impact uninitialized-value flaw was found in the NTFS3 filesystem driver in the Linux kernel.
Medium [CVE-2026-72424] fix NULL deref in shared IRQ handler at probe
In the Linux kernel, the following vulnerability has been resolved: rtc: msc313: fix NULL deref in shared IRQ handler at probe msc313_rtc_probe() calls devm_request_irq() with IRQF_SHARED and &pdev->dev as the cookie, but platform_set_drvdata() is only called later after the clock setup. With a shared IRQ line, another device on the same line can trigger the handler in that window. The handler does dev_get_drvdata() on the cookie, gets NULL, and dereferences priv->rtc_base in interrupt context. Pass priv as the cookie directly so the handler reads it from dev_id without the lookup, removing the dependency on probe order. During the probe phase, a shared Interrupt Request (IRQ) handler could be triggered by another device before the necessary driver data was fully initialized. This could lead to a null pointer dereference, where the system attempts to access an invalid memory location. A local attacker could potentially exploit this to cause a system crash, leading to a denial of service. A low impact flaw was found in the Linux kernel MStar MSC313 RTC driver. Red Hat rates the impact of this flaw as low because triggering it requires a narrow probe-time race on hardware where this RTC device shares its interrupt line with another device, even though the Red Hat CVSS 3.1 base score is 5.5.
Medium [CVE-2026-72215] Ensure 32-bit stack location for o32 prom_printf
In the Linux kernel, the following vulnerability has been resolved: MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf() In 64-bit configurations calling any firmware entry points from a kernel thread other than the initial one will result in a situation where the stack has been placed in the XKPHYS 64-bit memory segment. Consequently the stack pointer is no longer a 32-bit value and when the 32-bit firmware code called uses 32-bit ALU operations to manipulate the stack pointer, the calculated result is incorrect (in fact in the 64-bit MIPS ISA almost all 32-bit ALU operations will produce an unpredictable result when executed on 64-bit data) and control goes astray. This may happen when no final console driver has been enabled in the configuration and consequently the initial console continues being used late into bootstrap, or with an upcoming change that will switch the zs driver to use a platform device, which in turn will make the console handover happen only after other kernel threads have already been started, and the kernel will hang at: pid_max: default: 32768 minimum: 301 or somewhat later, but always before: cblist_init_generic: Setting adjustable number of callback queues. has been printed. It seems that only the prom_printf() entry point is affected.