---
id: "CVE-2026-91007"
page: "https://infrastack.ai/live/CVE-2026-91007"
kind: "vulnerability"
aliases: ["CVE-2026-91007"]
title: "Zephyr: charger driver lets user threads hijack kernel control flow"
severity: "high"
cvss: 7.8
epss: null
exploited: false
status: "open"
category: "infrastructure"
products: []
ecosystems: []
tags: ["bq2518x", "charger-drivers", "embedded", "infrastructure", "max20335", "pf1550", "zephyr"]
not_affected_if: ["default-config", "no-charger-driver", "supervisor-only-callers"]
published_at: "2026-11-12T16:19:21+00:00"
first_seen_at: "2026-11-12T16:44:02+00:00"
updated_at: "2026-11-12T16:45:43+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-91007", "first_seen_at": "2026-11-12T16:44:02+00:00"}]
exploit_sources: []
---

# Zephyr: charger driver lets user threads hijack kernel control flow

Link for people: https://infrastack.ai/live/CVE-2026-91007 (this .md is for agents)

Zephyr's charger driver API does not check two function-pointer properties when user-mode threads pass them in, so an unprivileged thread can store an arbitrary pointer that the kernel later calls. The read path also leaks a kernel code address to user mode, and a user thread can clear notifiers set by supervisor code.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check whether `CONFIG_USERSPACE` is enabled in the Zephyr build configuration (`prj.conf` or the board Kconfig).
- Check whether the firmware uses the `max20335`, `pf1550` or `bq2518x` charger drivers.
- Check whether any user-mode thread is granted a charger device object.

## Fix

- Apply the upstream patch linked in the sources; the sources do not name a fixed Zephyr release version.

## Timeline

- 2026-11-12T16:44:02+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-91007

## Documents

- [advisory] Vendor advisory: github.com https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-jr35-f52j-fm88
- [fix] Patch: github.com https://github.com/zephyrproject-rtos/zephyr/commit/5467b7a73fe093d7e9562ee15c321cf8f1639d17

## From the sources

The user-mode syscall verifiers for the charger driver API in drivers/charger/charger_handlers.c did not inspect the prop argument before copying union charger_propval across the user/kernel boundary. Two members of that union are function pointers — status_notification (CHARGER_PROP_STATUS_NOTIFICATION) and online_notification (CHARGER_PROP_ONLINE_NOTIFICATION), declared in include/zephyr/drivers/charger.h — and z_vrfy_charger_set_prop() forwarded the caller-supplied union verbatim to the driver's set_property callback for any property. z_vrfy_charger_get_prop() had the mirror defect and copied the stored kernel callback address back out to user memory.

With CONFIG_USERSPACE enabled, any user-mode thread that has been granted a charger device object could call charger_set_prop() with CHARGER_PROP_STATUS_NOTIFICATION or CHARGER_PROP_ONLINE_NOTIFICATION and an arbitrary pointer value. Drivers that implement these properties — drivers/charger/charger_max20335.c, drivers/charger/charger_pf1550.c and drivers/charger/charger_bq2518x.c — store the pointer in device data and later invoke it from their interrupt work handlers, which run in supervisor mode, on any charger state change such as a cable plug/unplug.

The result is a control-flow hijack at kernel privilege from an unprivileged thread, defeating the isolation that CONFIG_USERSPACE is meant to provide; the read path additionally disclosed a kernel code address to user mode, and clearing a notifier installed by a supervisor thread let user mode suppress charger notifications. Supervisor-mode callers of charger_set_prop()/charger_get_prop() are unaffected.

The fix makes both verifiers reject the two notifier properties outright — including when the supplied callback is NULL, since the notifiers are device state — and adds a BUILD_ASSERT on CHARGER_PROP_COMMON_COUNT so that new properties force a re-review of the union's user-mode safety.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_