> It’s the kernel. Nothing a user space library can do should ever be able to call this.
replyI don't follow. An application might see this kind of crash if it has a bug causing it to access a page while another thread is mapping or unmapping that page. That would be a bug in mallocng, musl or ripgrep. Or, as someone else mentioned, it could be bug in the processor's virtual memory logic that has the same effect. Why do you say it can only be a kernel bug?
It got traced to a race condition in munmap() in the kernel. The inefficient musl allocator simply triggers it more easily.
replyIt got arm-waved to a race condition in munmap(). Claude (or a distill of Claude) didn't identify a race, it just convinced itself that was the cause.
replyAndy Lutomirski seems to think that it is a bug: https://lore.kernel.org/all/CALCETrXbj__SFQMzPZhES5y6-sh4np-...
replyI looked at the explanation, and it seems to be at very least plausible. The kernel version bisection also lines up. We'll see if the proposed patch fixes this.
User code calls kernel code all the time - just not by its address.
reply