So it seems that I managed to work-around/fix the issue by applying this diff. I was wrong, it still is happening, though at times it seemed like it worked.

The diff consists of setting up the runtime more similarly to how libc does it. Note this issue may very well be me making wrong assumptions about how ccgo works. @cznic may know more.

note that your code fails checkptr:

$ go test -race .
fatal error: checkptr: pointer arithmetic result points to invalid allocation

I've been misusing the API as cznic points out in slack.

Every uinptr-shaped C pointer you pass to the transpilled code must be either pinned (slow in my benchmarks: https://modern-c.blogspot.com/2023/07/ccgov4-experiment-trying-new.html) or it must be allocated in the C memory via libc.Xmalloc or libc.Xrealloc.
But here https://github.com/soypat/fatfs/blob/b4eba67a429e2182ef3dcc87e28cbe976d2c2cf0/ext.go#L10 the address of a local variable fss from here https://github.com/soypat/fatfs/blob/b4eba67a429e2182ef3dcc87e28cbe976d2c2cf0/fatfs_test.go#L30 is passed, for example. You can get away with package-level variables, you cannot do that with local ones as they may end up in the stack and Go can move stacks. The conversion to uintptr a) breaks the addr-pointee invariant b) allows the Go runtime to possibly free the memory while the transpiled code still uses it.
I know the ccgo ABI is not yet documented anywhere and that's my fault, sorry.
This is only about "static" analysis of the bug, I haven't looked for any logic errors.

And upon setting up a fixture to test if runtime.Pinner has any effect I found enabling pinning on pointer arguments actually fixed the bug.

As for the invalid allocation result, I'm not sure what's the root cause. I looked at the stack trace and the stuff that's going on in ccgo is beyond my expertise. I think we can close this as solved if that's alright with y'all.