Codex reaches root on a Samsung TV by abusing world-writable driver access

A new research project shows how far AI-assisted device hacking has moved. Security researchers at CALIF gave OpenAI’s Codex a browser-level foothold on a real Samsung smart TV, then let it work from there. Codex found a path to root by abusing writable kernel driver interfaces that should never have been exposed to an unprivileged context.

The finding matters because it did not depend on a magic prompt or a hand-fed exploit recipe. CALIF says the team gave Codex a live target, the matching Samsung KantS2 firmware source tree, and the goal of reaching root. The model then had to enumerate the device, inspect the source, test its assumptions on the TV, and build a working privilege-escalation chain on its own.

BEST SPRING 2026 DEALS

Editor's Choice

Private Internet Access

Access content across the globe at the highest speed rate.

70% of our readers choose Private Internet Access

70% of our readers choose ExpressVPN

ExpressVPN

Browse the web from multiple devices with industry-standard security protocols.

Nord VPN

Faster dedicated servers for specific actions (currently at summer discounts)

The exploit chain started from code execution inside the TV’s browser app under a low-privilege user context. From there, Codex identified Samsung’s ntk driver family as reachable attack surface, worked around Samsung’s execution restrictions, and eventually changed the browser process credentials in memory until the shell reported uid 0 and gid 0.

How the chain worked

CALIF’s write-up says the TV ran Linux kernel 4.1.10 on Samsung’s Tizen platform. The researchers also note that Samsung’s Unauthorized Execution Prevention blocks unsigned binaries from running off disk, so the testing setup used a memfd-based helper to launch code directly from memory instead. Older public research on Samsung TVs describes UEP the same way: binaries must be signed, and the kernel enforces that rule.

After reconnaissance, Codex focused on three writable device nodes from the ntk stack: ntkhdma, ntksys, and ntkxdma. The key issue sat in /dev/ntksys, which CALIF says let user space register a physical memory address and size, then map that memory into its own process through mmap. In simple terms, that gave low-privilege code a direct read-write window into physical memory.

The write-up traces the root cause to two problems that should not have shipped together. A udev rule reportedly exposed the interface with mode 0666, and the driver validated the slot index but not whether the requested memory overlapped sensitive kernel-owned ranges. Once Codex proved the primitive worked, it used memory clues from the live system to find the browser process credential structure and zero out the UID and GID fields.

Why this finding stands out

This is not just a Samsung TV story. It is also a story about what an AI coding agent can now do when researchers give it a realistic post-exploitation position. CALIF says Codex was not told to inspect ntksys, not told to target physical memory, and not given instructions about Linux kernel credentials. It still found the route and made it work under real device constraints.

That does not mean Codex acted like an unsupervised internet threat actor in the wild. The researchers provided the foothold, the source tree, the wrapper needed to bypass execution limits, and a controlled environment. Still, the result lowers the bar for vulnerability research and exploit development on embedded devices, especially when vendors leave high-risk interfaces reachable from low-trust app contexts.

Samsung’s own public security language makes the contrast hard to miss. Samsung says it takes security and privacy seriously, continuously audits products, and provides dedicated reporting channels for TV vulnerabilities. The company also says Samsung Knox on TVs helps protect hardware, platform, and service layers. If CALIF’s findings affect shipping or closely related firmware, they raise direct questions about driver permission design, least privilege, and review of third-party kernel components inside consumer devices.

What the research shows at a glance

What vendors should fix now

• Remove world-writable permissions from any memory-management or DMA-related device nodes.
• Audit udev rules for 0666 access on privileged driver interfaces.
• Validate physical memory ranges before any mmap operation.
• Restrict browser and app contexts from reaching dangerous kernel surfaces.
• Review third-party and vendor driver stacks under a least-privilege model.

FAQ