[GH-ISSUE #20] AgentENV fails on kernels affected by the ublk ADD_DEV initialization regression #11

New issue

Open

opened 2026-10-29 14:18:19 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-29 14:18:19 +00:00

Owner

Originally created by @yingdi-shan on GitHub (Jul 27, 2026).
Original GitHub issue: https://github.com/kvcache-ai/AgentENV/issues/20

Summary

AgentENV cannot create ublk-backed block devices on kernels affected by a ublk initialization-order regression. The first UBLK_U_CMD_ADD_DEV operation can trigger a kernel NULL-pointer dereference, after which the command never completes and AgentENV cannot create or run sandboxes.

It affects any kernel containing:

529d4d632788 (ublk: implement NUMA-aware memory allocation)
without its prerequisite 011af85ccd87 (ublk: reorder tag_set initialization before queue allocation)

Known affected kernels

Upstream stable Linux 6.18.4
Upstream stable Linux 6.18.5
Arch Linux 6.18.4-arch1-1
Ubuntu 6.17.0-1015-azure
Ubuntu 6.17.0-1018-azure is also reported as still affected

Other downstream kernels may be affected if they backported the NUMA change without the prerequisite reorder.

Known fixed or unaffected kernels

Upstream stable Linux 6.18.6 and later 6.18.y releases contain the fix
Kernels containing both commits are not affected
Older kernels without the NUMA change are not affected by this specific regression

References

Originally created by @yingdi-shan on GitHub (Jul 27, 2026). Original GitHub issue: https://github.com/kvcache-ai/AgentENV/issues/20 ## Summary AgentENV cannot create ublk-backed block devices on kernels affected by a ublk initialization-order regression. The first `UBLK_U_CMD_ADD_DEV` operation can trigger a kernel NULL-pointer dereference, after which the command never completes and AgentENV cannot create or run sandboxes. It affects any kernel containing: - `529d4d632788` (`ublk: implement NUMA-aware memory allocation`) - without its prerequisite `011af85ccd87` (`ublk: reorder tag_set initialization before queue allocation`) ## Known affected kernels - Upstream stable Linux `6.18.4` - Upstream stable Linux `6.18.5` - Arch Linux `6.18.4-arch1-1` - Ubuntu `6.17.0-1015-azure` - Ubuntu `6.17.0-1018-azure` is also [reported as still affected](https://github.com/actions/runner-images/issues/14175#issuecomment-5054177083) Other downstream kernels may be affected if they backported the NUMA change without the prerequisite reorder. ## Known fixed or unaffected kernels - Upstream stable Linux `6.18.6` and later `6.18.y` releases contain the fix - Kernels containing both commits are not affected - Older kernels without the NUMA change are not affected by this specific regression ## References - [Ubuntu Launchpad bug #2154635](https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/2154635) - [Upstream ublksrv issue #174](https://github.com/ublk-org/ublksrv/issues/174) - [Linux 6.18.6 fix](https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.18.6)

bsakaguchi commented

2026-10-29 14:18:20 +00:00

Author

Owner

@catyans commented on GitHub (Jul 31, 2026):

I can take a focused fail-fast guard for this. The runtime will detect the exact known-affected release families before entering the ublk device path, explain the required kernel upgrade, and provide an explicit environment override for vendor kernels that have backported the prerequisite fix. I will keep the detector pure/unit-tested and document the override; it will not probe ADD_DEV because that probe itself can trigger the kernel crash.

@catyans commented on GitHub (Jul 31, 2026): I can take a focused fail-fast guard for this. The runtime will detect the exact known-affected release families before entering the ublk device path, explain the required kernel upgrade, and provide an explicit environment override for vendor kernels that have backported the prerequisite fix. I will keep the detector pure/unit-tested and document the override; it will not probe ADD_DEV because that probe itself can trigger the kernel crash.

bsakaguchi commented

2026-10-29 14:18:20 +00:00

Author

Owner

@yingdi-shan commented on GitHub (Jul 31, 2026):

I think the only change needed is adding a warning to install.sh and docker-setup.sh

@yingdi-shan commented on GitHub (Jul 31, 2026): I think the only change needed is adding a warning to install.sh and docker-setup.sh

bsakaguchi referenced this issue

2026-10-29 14:18:40 +00:00

[GH-ISSUE #119] Add opt-in dirty-page tracking for memory snapshot page selection #38

bsakaguchi referenced this issue

2026-10-29 14:19:40 +00:00

[GH-ISSUE #441] Restore a sandbox from a snapshot with its original sandbox ID #106

bsakaguchi referenced this issue

2026-10-29 14:19:41 +00:00

[GH-ISSUE #441] Restore a sandbox from a snapshot with its original sandbox ID #106