CVE-2025-2953

What it actually does

The described flaw is a local denial-of-service condition in PyTorch 2.6.0+cu124 involving torch.mkldnn_max_pool2d. A local user or workload that can execute Python code using PyTorch can supply crafted tensor shapes, parameters, or execution paths that cause the affected function to crash, hang, or otherwise terminate the hosting process. The primary impact is availability loss of the Python process, notebook kernel, training job, inference worker, or container running the vulnerable code. It does not indicate remote code execution, privilege escalation, or data disclosure by itself. The affected-product metadata supplied with this record also lists Red Hat Enterprise Linux 7.3 kernel-related packages with fixed version 0:3.10.0-514.78.1.el7; organizations should validate the authoritative vendor advisory because the package list appears inconsistent with the PyTorch-specific vulnerability description.

Why it matters to the business

Successful exploitation can interrupt machine-learning workloads, batch training jobs, inference services, data science notebooks, or shared compute environments by crashing affected local processes. In multi-user research, CI, MLOps, or hosted notebook platforms, this can cause job failures, service instability, wasted GPU/CPU time, and delayed model delivery. Risk is moderated because exploitation requires local code execution or the ability to submit workloads that invoke the vulnerable PyTorch operation, EPSS is low, and the issue is not listed in CISA KEV or ransomware use; however, public disclosure means shared or semi-trusted compute environments should still treat it as an availability risk.

How an attack unfolds

An attacker first needs local execution in an environment where PyTorch 2.6.0+cu124 is installed, or access to a service that accepts user-controlled model code, tensor operations, plugins, notebooks, or submitted ML jobs. The attacker then runs a crafted PyTorch operation path that reaches torch.mkldnn_max_pool2d with inputs that trigger the denial-of-service condition. The vulnerable process may crash, hang, generate a core dump, or be killed by the runtime or operating system. In a single-user workstation this primarily disrupts the current workload; in shared ML infrastructure it can repeatedly terminate notebook kernels, training workers, inference processes, CI jobs, or containerized workloads until the vulnerable package is upgraded or untrusted execution is constrained.

How to fix it

Upgrade PyTorch to a vendor-fixed version newer than the affected 2.6.0+cu124 build as soon as it is available from the trusted package source used by the organization, such as pip, conda, container base images, or the OS vendor. Rebuild and redeploy ML containers, notebook images, CI runners, and inference images that bundle the vulnerable PyTorch version. If the exposure is tied to the Red Hat package metadata supplied with this record, update listed RHEL 7.3 AUS/E4S kernel-related packages to 0:3.10.0-514.78.1.el7 or later, including kernel, kernel-debug, kernel-devel, kernel-headers, kernel-tools, perf, and python-perf packages as applicable. Where immediate upgrade is not possible, restrict untrusted local code execution, isolate tenants with containers or VMs, enforce CPU/GPU and memory limits, disable or tightly control user-submitted model code, validate tensor shapes and pooling parameters at service boundaries, and configure process supervisors to restart failed workers without causing cascading outages.

How to confirm the fix worked

Confirm installed PyTorch versions across hosts, containers, virtual environments, and notebook images using package inventory tools and commands such as python -c 'import torch; print(torch.__version__)', pip show torch, conda list torch, or image SBOM scans. Verify that no deployed runtime reports PyTorch 2.6.0+cu124 or another vendor-identified vulnerable build. For Red Hat package exposure, verify kernel-related package versions with rpm -q kernel kernel-debug kernel-devel kernel-headers kernel-tools perf python-perf and confirm versions are 0:3.10.0-514.78.1.el7 or later where those packages are installed. After patching, rerun representative ML workloads that use max pooling and MKL-DNN/oneDNN paths to confirm stability. Also verify that rebuilt containers and notebook kernels are actually running the updated packages rather than stale cached images or virtual environments.

Typical attack path

1. Gain local shell, notebook, CI job, container, plugin, or workload-submission access to a system using the affected PyTorch build.
2. Confirm PyTorch 2.6.0+cu124 or another affected build is present and that MKL-DNN/oneDNN-backed operations are available.
3. Execute Python code that invokes torch.mkldnn_max_pool2d directly or through a model path using crafted tensor inputs or pooling parameters.
4. Trigger the vulnerable condition, causing the Python process, notebook kernel, training worker, or inference worker to crash, hang, or be forcibly terminated.
5. Repeat the operation to sustain denial of service against shared compute, job queues, or application workers.

How to detect it

To determine whether this was already exploited, review logs from systems that run PyTorch workloads, including application logs, notebook server logs, ML job scheduler logs, container runtime events, systemd journal entries, kernel logs, and crash/core-dump records. Look for repeated crashes, hangs, worker restarts, failed training or inference jobs, or notebook kernel deaths correlated with PyTorch operations and references to torch.mkldnn_max_pool2d, mkldnn_max_pool2d, MKLDNN, oneDNN, max_pool2d, SIGSEGV, SIGABRT, or out-of-memory/resource-exhaustion events. In Kubernetes or containerized environments, inspect pod restart counts, termination reasons, container exit codes, and logs around affected workloads. In shared environments, correlate crash timing with recent notebook cells, submitted jobs, user-created scripts, or model uploads that invoke PyTorch pooling operations. Because this is a denial-of-service issue rather than a malware-specific vulnerability, there may be no unique network IOC; evidence is most likely to appear as local process crashes, coredumps, and repeated workload failures.

• torch.mkldnn_max_pool2d
• mkldnn_max_pool2d
• MKLDNN
• oneDNN
• max_pool2d
• Segmentation fault
• SIGSEGV
• SIGABRT
• systemd-coredump
• /var/lib/systemd/coredump
• python: segfault
• python3: segfault
• kernel died
• KernelRestarter: restarting kernel
• Back-off restarting failed container
• CrashLoopBackOff
• OOMKilled
• torch.__version__ == '2.6.0+cu124'

What your security team should do

• Prioritize inventory of shared ML, notebook, CI, and inference environments where untrusted or semi-trusted users can execute Python/PyTorch code.
• Upgrade affected PyTorch installations and rebuild dependent containers or notebook images; separately validate the Red Hat package advisory mapping before applying kernel package remediation solely on the basis of this record.
• Apply tenant isolation, resource limits, and job timeouts for user-submitted ML workloads to reduce the blast radius of local denial-of-service flaws.
• Monitor for repeated Python, notebook kernel, training-worker, or inference-worker crashes that include mkldnn_max_pool2d or oneDNN/MKLDNN stack traces.
• Block direct exposure of arbitrary model execution or tensor-operation APIs to unauthenticated or untrusted users.
• Document compensating controls and exception owners for systems that cannot be upgraded immediately.