Subject: Re: PBDMA Signature Error — Need Reproduction Steps and Verification Path for CVE-2025-33182 /
CVE-2025-33177
Hi,
Thank you for the response. We are running JetPack 6.0 (L4T r36.x, kernel 5.15.136) on Orin and plan to backport the
fix rather than upgrade the full BSP, as we have a production fleet.
We have already diffed the nvgpu source between our current tree and r36.5 (kernel_oot_modules_src.tbz2). The only
security-relevant change is the addition of prof_obj_lock mutex to protect the profiler_objects linked list — across
these 5 files:
- include/nvgpu/gk20a.h — new struct nvgpu_mutex prof_obj_lock
- os/linux/driver_common.c — nvgpu_mutex_init(&g->prof_obj_lock)
- common/profiler/profiler.c — lock around nvgpu_list_add
- os/linux/ioctl_dbg.c — lock around 7 list traversals/modifications
- os/linux/ioctl_prof.c — lock around 2 nvgpu_profiler_free calls
All PBDMA code (pbdma_ga10b_fusa.c, fifo_intr_ga10b_fusa.c, hw_pbdma_ga10b.h) is byte-for-byte identical between our
version and r36.5.
We have three questions before we can confidently deploy this fix to production:
- How does the profiler race condition cause a PBDMA signature error?
Our error is a hardware-level PBDMA signature validation failure — bit 31 of pbdma_intr_0 (0x80000000), meaning the
PBDMA’s internal signature register no longer matches the expected 0xFACE value. This is detected by the PBDMA
hardware itself, not by software.
The r36.5 fix addresses a software race condition on the profiler_objects linked list (missing mutex). We understand
that a list corruption / use-after-free could cascade into GPU state corruption, but we would like NVIDIA to confirm
the causal chain. Specifically:
- Does the corrupted profiler object lead to stale or invalid GPU channel/context state being written to PBDMA
registers?
- Or does the use-after-free corrupt memory that overlaps with GPU command buffers or GPFIFO entries, which the PBDMA
then reads as invalid?
- Or is the connection indirect — the race destabilizes the driver state machine, eventually leading to the PBDMA
processing garbage commands?
Understanding the mechanism helps us assess whether this fix fully addresses our failure mode, or whether we have a
separate issue that happens to co-occur.
- How can we reproduce this issue on demand?
The error occurs intermittently after ~6.9 hours of uptime on our system. Our power monitoring data shows stable
rails (±1 LSB) at the time of failure, ruling out power-related causes. We need a deterministic reproduction path to
validate the fix. Some specific questions:
- Is there a known workload pattern that triggers the race? For example, does concurrent profiler attach/detach
(e.g., running nsys or ncu while GPU workloads are active) reliably trigger it?
- Can we stress-test the profiler path specifically — e.g., rapid NVGPU_DBG_GPU_IOCTL_ALLOC_PROFILER / FREE_PROFILER
from multiple threads?
- Is there a known minimum concurrency level (number of threads, sessions) that makes the race window large enough to
hit reliably?
Without a reproduction method, we cannot distinguish between “the fix resolved the issue” and “the issue is
intermittent and hasn’t appeared yet.”
- Is backporting only these 5 files sufficient, or are there dependencies we’re missing?
We confirmed the diff is limited to these 5 files within nvgpu. But we want to verify:
- Are there any changes outside of kernel_oot_modules_src.tbz2 (e.g., in the kernel itself, device tree, or firmware)
that are also required for the CVE fix?
- The CVE bulletin references two CVEs (CVE-2025-33182 and CVE-2025-33177). Are both addressed by this single
profiler mutex fix, or does one of them require changes in a different component?
- Are there any runtime dependencies on the mutex (e.g., CONFIG_NVGPU_PROFILER must be enabled in our kernel config)?
We have already applied the 5-file patch and it builds cleanly against our kernel 5.15.136 tree. We would like
confirmation that this is the complete fix before deploying to our fleet.
Thank you for your help.
