GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Guest kernel panic: NULL pointer dereference in fuse_dentry_revalidate (2.2.5) · Issue #2784 · orbstack/orbstack

Guest kernel panic: NULL pointer dereference in fuse_dentry_revalidate (2.2.5) #2784

New issue
Copy link
New issue
Copy link
Open
Open
Guest kernel panic: NULL pointer dereference in fuse_dentry_revalidate (2.2.5)#2784
Copy link

Description

@punkhop
punkhop
opened on Nov 5, 2026
Issue body actions

Describe the bug

The guest kernel panicked (NULL pointer dereference in fuse_dentry_revalidate) while a container process (libuv-worker, a Node app) was opening a file. That container had a macOS folder bind-mounted. The whole VM went down, and every container restarted.

Happened once on 2026-11-03 at 03:03 local time, after about 5.5 days of VM uptime. The host is a headless 24/7 Mac mini running 22 containers. 17 of them bind-mount macOS folders under /Users or external drives under /Volumes.

To Reproduce

Not reproducible on demand. Workload: long-running containers with many macOS bind mounts (Immich, Uptime Kuma, Homepage, Sonarr/Radarr, Home Assistant, Jellyfin).

Expected behavior

No guest kernel panic.

Diagnostic report (REQUIRED)

https://orbstack.dev/_admin/diag/orbstack-diagreport_2026-11-05T03-20-13.077707Z.zip

macOS 27.0.1 (26A434), Apple M4 (Mac16,10), 10 cores, 16 GiB
OrbStack 2.2.5 (2020500), Docker Engine 29.8.2, VM memory limit 10 GiB

Screenshots and additional context (optional)

Guest kernel log (vmgr.log):

👾 kernel | [473711.545884] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000368
👾 kernel | [473711.545925] Mem abort info:
👾 kernel | [473711.545934]   ESR = 0x0000000096000006
👾 kernel | [473711.545954]   SET = 0, FnV = 0
👾 kernel | [473711.545958]   EA = 0, S1PTW = 0
👾 kernel | [473711.545973] Data abort info:
👾 kernel | [473711.545977]   ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
👾 kernel | [473711.545982]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
👾 kernel | [473711.545987]   GCS = 0, Overlay = 0, DirtyBit = 0
👾 kernel | [473711.545991] user pgtable: 4k pages, 48-bit VAs, pgdp=000000011d38b000
👾 kernel | [473711.545997] [0000000000000368] pgd=0800000104bef403, p4d=0800000104bef403, pud=08000001f3ecb403, pmd=0000000000000000
👾 kernel | [473711.547029] Internal error: Oops: 0000000096000006 [#1]  SMP
👾 kernel | [473711.547693] Modules linked in: bluetooth crc16
👾 kernel | [473711.548759] CPU: 0 UID: 0 PID: 2240359 Comm: libuv-worker Not tainted 7.2.12-orbstack-00394-gbecdd6130068 #1 PREEMPTLAZY 
👾 kernel | [473711.548781] Hardware name: orbstack,virt (DT)
👾 kernel | [473711.548793] pstate: 41400005 (nZcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
👾 kernel | [473711.548807] pc : fuse_dentry_revalidate+0x12c/0x3b8
👾 kernel | [473711.549675] lr : fuse_dentry_revalidate+0xf8/0x3b8
👾 kernel | [473711.549686] sp : ffff0001984a7aa0
👾 kernel | [473711.549814] Call trace:
👾 kernel | [473711.549818]  fuse_dentry_revalidate+0x12c/0x3b8 (P)
👾 kernel | [473711.549827]  path_openat+0xe74/0x1e08
👾 kernel | [473711.549835]  do_file_open+0x9c/0x160
👾 kernel | [473711.549842]  __arm64_sys_openat+0x124/0x200
👾 kernel | [473711.549851]  do_el0_svc+0x70/0xe8
👾 kernel | [473711.549859]  el0_svc+0x28/0x78
👾 kernel | [473711.550118]  el0t_64_sync_handler+0x40/0x100
👾 kernel | [473711.550127]  el0t_64_sync+0x154/0x158
👾 kernel | [473711.550175] Code: f829311f 17ffffdf 374010d5 f9401688 (f941b517) 
👾 kernel | [473711.550185] ---[ end trace 0000000000000000 ]---
👾 kernel | [473711.550194] Kernel panic - not syncing: Oops: Fatal exception
👾 kernel | [473711.550208] SMP: stopping secondary CPUs

The next day, the same machine had a different VM crash (a hypervisor vCPU panic). It is filed as #2785.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402520 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.