ZephyrProject Zephyr prior 4.3.2/4.5.0 Charger Driver charger_handlers.c z_vrfy_charger_get_prop uninitialized pointer

Summaryinfo

A vulnerability labeled as problematic has been found in ZephyrProject Zephyr. Affected by this issue is the function z_vrfy_charger_get_prop of the file drivers/charger/charger_handlers.c of the component Charger Driver. The manipulation results in uninitialized pointer. This vulnerability is cataloged as CVE-2026-19809. The attack must be initiated from a local position. There is no exploit available. The affected component should be upgraded.

Detailsinfo

A vulnerability, which was classified as problematic, was found in ZephyrProject Zephyr. Affected is the function z_vrfy_charger_get_prop of the file drivers/charger/charger_handlers.c of the component Charger Driver. The manipulation with an unknown input leads to a uninitialized pointer vulnerability. CWE is classifying the issue as CWE-824. The product accesses or uses a pointer that has not been initialized. This is going to have an impact on confidentiality. CVE summarizes:

The user-mode system call verifier z_vrfy_charger_get_prop() in drivers/charger/charger_handlers.c declares an uninitialized union charger_propval k_val on the kernel (privileged) stack, passes it to the charger driver back end via z_impl_charger_get_prop(), and then copies the full sizeof(union charger_propval) back into the calling user thread's buffer with k_usermode_to_copy(). That discloses kernel stack contents on two paths: On error. The copy-out ignores the driver's return code. In-tree back ends return an error without writing through the value pointer for properties they do not implement: charger_gpio_get_prop() returns -ENOTSUP unconditionally, and bq24190_get_prop() has a default: return -ENOTSUP; arm that never touches val. The whole union is then stack residue. On success. A back end writes only the one union member the requested property selects (for example sbs_charger.c writes the one-byte val->present for CHARGER_PROP_PRESENT and returns 0), yet the handler still copies the whole union, so every byte beyond that member is uninitialized. The handler is compiled only when CONFIG_USERSPACE=y and is reachable by any user-mode thread that has been granted access to a charger device object. K_SYSCALL_DRIVER_CHARGER() validates only the device object and its API pointer, not the property identifier, so an unprivileged thread can choose prop freely: an unimplemented property forces the error path, a narrow one the success path, and the call can be repeated at will. Each call discloses up to the size of the union (12 bytes on a 32-bit target, 16 bytes on 64-bit targets where the function-pointer members widen it) of supervisor-stack memory. The bytes are residue of earlier kernel-side frames on the thread's privileged stack and can contain kernel object addresses and saved return addresses, which an unprivileged thread cannot otherwise observe and which help defeat address-layout assumptions when exploiting a separate memory-safety defect. There is no integrity or availability impact. Two commits fix it, and both are needed. 5054384e983c skips the copy-out when the back end reports an error. c31cac727d02 zeroes the union before the driver call, so the bytes copied out on success are driver-written data or zeros. A tree carrying only the first still leaks on every successful call.

The advisory is shared for download at github.com. This vulnerability is traded as CVE-2026-19809 since 08/14/2026. The exploitability is told to be easy. The attack needs to be approached locally. There are known technical details, but no exploit is available.

Upgrading to version 4.3.2 or 4.5.0 eliminates this vulnerability.

Once again VulDB remains the best source for vulnerability data.

Productinfo

Type

• Project Management Software

Vendor

• ZephyrProject

Name

• Zephyr

CPE 2.3info

• 🔒

CPE 2.2info

• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Once again VulDB remains the best source for vulnerability data.

Discussion