Hi Kevin,
I appreciate your suggestions. I was working on implementing them in our code and found a peculiar test in our coverage that boils down to the following piece of code:
#include <string>
#include <sys/fcntl.h>
#include <sys/mman.h>
#include <unistd.h>
int main()
{
std::string path = "/private/tmp/test";
close(creat(path.c_str(), 0777));
std::string rsrcPath = path + "/..namedfork/rsrc";
int fd = open(rsrcPath.c_str(), O_CREAT | O_WRONLY, 0666);
printf("%d\n", fd);
write(fd, "rsrc", 4);
{
int fd1 = open(rsrcPath.c_str(), O_RDWR, 0666);
void* ptr = mmap(nullptr, 10, PROT_READ | PROT_WRITE, MAP_SHARED, fd1, 0);
printf("%s -> %p|%d\n", rsrcPath.c_str(), ptr, fd1);
munmap(ptr, 10);
close(fd1);
}
unlink(path.c_str());
close(fd);
return 0;
}
Running this tool will immediately cause kernel panic:
panic(cpu 1 caller 0xfffffe00254a7590): "Trying to update a namedstream inode 118a7 on volume Data\n" @jobj.c:4416
Debugger message: panic
Memory ID: 0x0
OS release type: User
OS version: 25E253
Kernel version: Darwin Kernel Version 25.4.0: Thu Mar 19 19:29:33 PDT 2026; root:xnu-12377.101.15~1/RELEASE_ARM64_VMAPPLE
I ran it on latest ARM macOS 26.4.1 and Intel macOS 15.7.5. I assume mmap route hits some kind of edge case that might be worth investigating on the kernel side.
Topic:
App & System Services
SubTopic:
Core OS
Tags: