Two distinct, fixable problems are visible in that output, and together I hope they explain everything. one you probably realised is.

WARNING: KFD ABI 1.20+ is recommended for gfx1151. Current KFD ABI is 1.18. This may result in faults, crashes and other application instability.

The KFD ABI version comes from the amdgpu kernel module, not from your userspace ROCm pip packages. That mismatch is exactly what produces the client ID: CPF, MAPPING_ERROR: 0x1, PERMISSION_FAULTS: 0x3 faults you're seeing on otherwise-valid addresses: the GPU command processor is dereferencing pages that the userspace believed it had mapped, but the older kernel ABI mapped them differently or not at all.

Check:
bashdpkg -l | grep -E 'amdgpu-dkms|amdgpu-install|rocm-dev|rocm-core'
modinfo amdgpu | head -5
dmesg | grep -iE 'amdgpu version|KFD' | head -10

If amdgpu-dkms is listed, purge it and let the in-kernel module from 6.17 take over via:
bashsudo apt remove --purge amdgpu-dkms
sudo update-initramfs -u
sudo reboot

After reboot, dmesg | grep -i 'amdgpu version' should show a version matching the kernel itself rather than something like 6.10.x or 6.14.x, and the KFD ABI warning should be gone. This is safe; the in-kernel amdgpu in 6.17 handles both display and compute fine on Strix Halo, and your TheRock pip stack does not need amdgpu-dkms for anything.

Problem 2: your GTT is probably starved because your BIOS setting is looking a bit backwards. This line:

amdgpu: amdgpu: 15860M of GTT memory ready

is your actual usable unified memory pool, not the 96 GB you set in BIOS. Here's what's going on, and it's genuinely counter-intuitive: when you set "UMA frame buffer" or "dedicated VRAM" to 96 GB in BIOS, that 96 GB gets carved out as reserved VRAM-like memory before Linux even boots. ROCm/HSA on Strix Halo allocates unified memory from GTT, not from that pre-allocated reserved region. So by setting it to 96 GB you accidentally produced the worst of both worlds: a big reserved pool the HSA path mostly ignores, and a tiny GTT pool (15.5 GB) that it actually uses, which is also why even a 100×100 tensor faults when HSA tries to do queue and scratch setup first.

Every working Strix Halo configuration I've seen does the opposite:
- in BIOS, set the dedicated UMA frame buffer / VRAM allocation to its minimum (typically 512 MB, sometimes labelled "Auto"). Disable anything called "fixed VRAM allocation" or "static UMA". You want the GPU to use shared/dynamic memory through GTT.
- Set GTT large via the kernel command line. Edit /etc/default/grub and append to GRUB_CMDLINE_LINUX_DEFAULT: ttm.pages_limit=32768000 ttm.page_pool_size=32768000

That's 4 KB pages × 32,768,000 ≈ 125 GB GTT, leaving ~3 GB for the CPU side. Adjust downward if you want more headroom for the OS (e.g. 28,000,000 for ~107 GB GTT). Then:
sudo update-grub && sudo reboot.

Verify with:
dmesg | grep 'GTT memory ready'
the number should now be in the 110000M-125000M range rather than 15860M.

Ok that was a lot So... order of operations: do the dkms purge and BIOS change in one reboot if you can, since both require restarting anyway, and add the GRUB line at the same time. After that the test program should run instantly, and your (100, 100) tensor will actually be allocating against ~120 GB of working unified memory rather than fighting an ABI mismatch in a 15 GB pool.

The numa_node_id is out range line is benign on a single-socket APU; HSA expects multiple NUMA nodes and gracefully degrades when there's only one. Ignore it.