[Advisory] MPI, Debugger and Profiler Behavior After CVE-2026-46333 Mitigation​

/in , , , /by

Dear NSCC Users,

Red Hat published a security advisory (CVE-2026-46333, Red Hat Security Bulletin RHSB-2026-004) describing a local privilege-escalation vulnerability in the Linux kernel. NSCC has applied Red Hat’s recommended mitigation on ASPIRE 2A on 17 May 2026.

The same mitigation has also been applied to ASPIRE 2A+ as a precautionary measure, while we await a response and further guidance from NVIDIA.

This is a defense-in-depth measure intended to ensure continued protection through the planned June kernel upgrade, where the underlying conditions may change. Please be assured that no NSCC user data, jobs, or accounts are known to have been affected by this vulnerability.

However, because this mitigation restricts certain kernel-level process tracking and memory access, it will temporarily alter the behavior of development tools and MPI frameworks as detailed below.

 

Debuggers and Profilers
Debuggers, profilers, and tracing tools that rely on ptrace may not be functional as expected under this mitigation. The most common symptom is “Operation not permitted” when a tool attempts to inspect or attach to a process.

General Guideline: Workflows where a tool starts your program from the beginning are more likely to continue working. Workflows where a tool reaches into or attaches to a process that is already running will likely fail.

If your usual workflow involves attaching to an existing PID (e.g., gdb -p, strace -p, perf -p, nsys attach, ncu –pid, py-spy –pid, gcore), expect it to fail or behave incorrectly.

Tools that may not be functional as expected include, but are not limited to:

  • gdb, cuda-gdb
  • strace, ltrace
  • perf (record, stat, top)
  • nsight-systems (nsys), nsight-compute (ncu)
  • VTune
  • CrayPat (pat_run), perftools-lite
  • valdrind4hpc, heaptrack (in some modes)
  • gcore, py-spy, rr, and other tools that read /proc/<pid>/mem

 

Important Note: Arm Forge (DDT, MAP, PR) is known not to work under this mitigation and should not be used until further notice.

This list is not exhaustive. If you use a tool not mentioned here and observe unexpected behavior, assume it may be related to this change.

MPI and Intra-node Communication
Cray MPICH’s shared-memory single-copy optimizations (XPMEM, cross-memory-attach) rely on kernel mechanisms that this mitigation also gates. Without action, Cray MPICH jobs would be expected to fail or hang on intra-node communication.

We have applied site-wide environment defaults to disable the affected single-copy paths:
export MPICH_CH4_XPMEM_LMT_MSG_SIZE=NONE
export MPICH_SMP_SINGLE_COPY_MODE=NONE

With these in place, Cray MPICH is expected to function normally. The exports are applied in the default module environment, so you do not need to add them to your job scripts unless you have explicitly overridden them. There may be a small performance impact on large intra-node messages, but correctness is preserved.

OpenMPI and NCCL are not affected and require no changes.

If you build your own MPI from source, or use a non-default MPI distribution, please apply equivalent flags to disable single-copy / cross-memory-attach mechanisms in your implementation.

Next Steps
We will revisit and roll back this mitigation once patched kernels are available, validated, and deployed in June. Until then, thank you for your patience and cooperation as you adapt your workflows.

If a particular task or business-critical workflow is materially impacted, please reach out to us so we can assist.

Should you have any questions or need assistance, please contact our Helpdesk via the Service Desk Portal or email us at [email protected].

Thank you.

Warm regards,
The NSCC Team