`fs.realpath.native` causes `SIGABRT` on darwin when the realpath is really long

[ashi009]

• Version: v12.12.0 and v14.8.0
• Platform: Darwin Kernel Version 19.6.0: Sun Jul 5 00:43:10 PDT 2020; root:xnu-6153.141.1~9/RELEASE_X86_64
• Subsystem: fs

What steps will reproduce the bug?

$ LONG_PATH='/tmp/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/long/path/254B'
$ SHORT_LINK='/tmp/short'
$ mkdir -p "${LONG_PATH}"
$ ln -s "${LONG_PATH}" "${SHORT_LINK}"
$ node -e "fs.realpathSync.native('${SHORT_LINK}/file-not-exist')"
node(60274,0x10eabedc0) malloc: Incorrect checksum for freed object 0x104805aa0: probably modified after being freed.
Corrupt value: 0x7473697865
node(60274,0x10eabedc0) malloc: *** set a breakpoint in malloc_error_break to debug
Abort trap: 6

How often does it reproduce? Is there a required condition?

Almost every time.

What is the expected behavior?

return ENOENT.

What do you see instead?

Crash with SIGABRT

Additional information

The bug is confirmed by the libuv and the patch is underway: libuv/libuv#2965

[bnoordhuis]

After the patch, the buffer overrun threshold should be 1025 on darwin

To clarify: there's no buffer overrun anymore after libuv/libuv#2965 lands because paths are never > 1024 on that platform.

The problem was that libuv was using the wrong constant, one that was considerably smaller.

[ashi009]

After the patch, the buffer overrun threshold should be 1025 on darwin

To clarify: there's no buffer overrun anymore after libuv/libuv#2965 lands because paths are never > 1024 on that platform.

The problem was that libuv was using the wrong constant, one that was considerably smaller.

Correct, I'll scratch the last bit.

[bnoordhuis]

This was fixed by the libuv upgrade in #34915 and is scheduled for release today, see #34852.

I don't know exactly when it'll be back-ported to v12.x and v10.x, that's up to the @nodejs/releasers.

[richardlau]

The libuv update from #34915 went out in Node.js 12.19.0 (#35401).

[richardlau]

At this late stage it's very unlikely libuv will be updated again in Node.js 10.x.