OhrTech security bulletins

OHR-2026-007: Unisoc kernel DVFS driver flaw (CVE-2026-87765): fixed

Mon, 19 Oct 2026 16:45:00 GMT

What the vulnerability is

Unisoc reports that its kernel APsys DVFS driver, which manages processor power and frequency, does not properly validate a frequency index. That can cause an out-of-bounds read or corrupt a hardware register, leading to system instability or denial of service. Unisoc rates it 5.5 (Medium): it needs local access and some privileges, and it affects availability only, not data. Its affected chips include the T7200, the current name of the T606 in OhrTech devices.

How it affected OhrTech devices

The Foundation OS kernel includes this driver, ported from Unisoc's code, so the flaw was present. On OhrTech devices only a privileged system process allowed by our SELinux policy could reach it; apps and the shell cannot. The worst outcome was a crash or instability, not access to data. We know of no exploitation, and the U.S. Cybersecurity and Infrastructure Security Agency's assessment records none.

What we did

We fixed the flaw in the Foundation OS kernel. While reviewing the same driver, we found a related local denial-of-service in it, introduced when the driver was ported, and fixed that too. Both fixes are in Foundation OS release 2026101902, released on October 19, 2026.

This update does not change the security patch level, which stays at 2026-10-01. To tell whether a device has the fix, check its Foundation OS release, not its patch level.

Who needs to act

If you approve updates manually, approve release 2026101902 or later. Devices on release 2026101901 or earlier still have the flaw until they take it.

Credit

Unisoc disclosed this flaw in its October 2026 security bulletin and did not name who found it.

OHR-2026-005: Unisoc modem input validation flaw (CVE-2025-31718): fixed

Sat, 17 Oct 2026 12:00:00 GMT

What the vulnerability is

Unisoc reports a flaw in how its modem firmware validates input from the network. It can be triggered remotely, with no user interaction and no privileges, and Unisoc describes the impact as a possible system crash that "could lead to remote escalation of privilege". Unisoc rates it 7.5 (High) and lists the T606, T612 and T616 among the affected chips.

What we did

Modem firmware is a closed Unisoc binary, so this can only be fixed by shipping newer firmware. The Foundation OS ships modem firmware from a build at security patch level 2026-09-01, which covers CVE-2025-31718: Google lists the fix in the December 2025 Android Security Bulletin at patch level 2025-12-05.

Who needs to act

Nobody. The fix is part of the Foundation OS that every OhrTech device runs.

Credit

Unisoc disclosed this flaw in its October 2025 security bulletin and did not name who found it.

OHR-2026-004: Unisoc tee service out-of-bounds writes (CVE-2022-48373, CVE-2022-48374): not affected

Sat, 17 Oct 2026 12:00:00 GMT

What the vulnerability is

Unisoc's "tee service" is missing a bounds check in two places, allowing out-of-bounds writes. Unisoc describes the impact as local denial of service, with System execution privileges needed; CISA rates them 4.4 (Medium). Its affected list includes the T606, T612 and T616, and it fixed both in its May 2023 security bulletin.

Why OhrTech devices were never vulnerable

The Trusted Execution Environment (TEE) is the isolated, secure-world operating system that holds keys and runs trusted code apart from Android. On these chips, Unisoc ships its own modified version of Google's Trusty, with its own trusted apps and the Android services that talk to them.

The Foundation OS does not use any of it. We replaced Unisoc's TEE and its services with the reference Trusty from the Android Open Source Project, so the affected Unisoc code has never been part of the software on an OhrTech device.

Who needs to act

Nobody.

Credit

Unisoc disclosed both flaws in its May 2023 security bulletin and did not name who found them.

OHR-2026-003: Unisoc trusty service out-of-bounds writes (CVE-2024-39427, CVE-2024-39428): not affected

Sat, 17 Oct 2026 12:00:00 GMT

What the vulnerability is

Unisoc's "trusty service" is missing a bounds check in two places, allowing out-of-bounds writes. Unisoc describes the impact as local denial of service, with System execution privileges needed, and rates them 5.1 and 6.8 (Medium). Its affected list includes the T606, T612 and T616, and it fixed both in its July 2024 security bulletin.

Why OhrTech devices were never vulnerable

Who needs to act

Nobody.

Credit

Unisoc disclosed both flaws in its July 2024 security bulletin and did not name who found them.

OHR-2026-002: Unisoc TEE DRM trustlet buffer overflow (CVE-2023-33913): not affected

Sat, 17 Oct 2026 12:00:00 GMT

What the vulnerability is

Unisoc's TEE includes a trusted app for cryptography used by DRM: a Widevine interface plus Unisoc's own OEMCrypto API. Laszlo Szapula of TASZK Security Labs found that one of its commands copies a sender-supplied number of bytes onto a fixed-size stack buffer without checking the size, and the trustlet has no stack protection. A program able to talk to the trustlet can overflow the buffer and run code inside the TEE. Read TASZK's advisory.

Unisoc lists the T606, T612, T616, T610, T618, T760, T770, T820 and S8000 as affected, and fixed it in its August 2023 security bulletin. NVD rates it 7.2 (High).

Why OhrTech devices were never vulnerable

Who needs to act

Nobody.

Credit

Found by Laszlo Szapula of TASZK Security Labs, who reported it to Unisoc in May 2022 and published a detailed advisory. Thank you.

OHR-2026-001: Unisoc VoLTE video call exploit: patched by OhrTech, no vendor fix

Sat, 17 Oct 2026 12:00:00 GMT

What the vulnerability is

Independent security researcher 0x50594d, working with SSD Secure Disclosure, found and published two flaws in the modem firmware shared by several Unisoc chips: the T606, T612, T616 and T7250. These chips are used in budget phones from Motorola, Xiaomi and Realme. The OhrTech Aleph uses the T606.

Stage one: code on the modem, from a video call. The modem mishandles the session description carried in the signalling that sets up a video call. A specially crafted call corrupts the modem's memory and can run the attacker's code on it. Read the researcher's write-up of the modem flaw.

Stage two: from the modem to the Android kernel. Code running on the modem can switch off the modem's own memory protection, then read and write all of the device's physical memory, including the Android kernel's code. Read the researcher's write-up of the kernel escalation.

Together, the two give an attacker full control of the phone from a single video call. The researchers demonstrated the chain on their own test cellular network, against a Motorola E13, a Xiaomi Redmi A5 and a Realme C33.

What the chip maker did

Nothing. SSD reports that it tried to reach Unisoc through several channels before each publication and received no response. No CVE has been assigned, and Unisoc has not fixed the flaw, even in its newest modem firmware.

This is typical of the market rather than rare: more than 40% of Android devices in the world no longer receive security updates at all.

What we did

We patched the modem ourselves. With no fix coming from Unisoc, we corrected the flaw in the modem firmware directly. The patched modem ships on every OhrTech device.

The modem cannot change the kernel's code. Stage two works by writing into the kernel. A hardware memory monitor now guards the kernel's code and read-only data: any write to them from the modem, or from any other peripheral, halts the device the moment it happens. On restart, the kernel is loaded again from the signed, verified image.

We hardened the interface between the modem and the kernel. The kernel talks to the modem and the device's other processors through shared memory. We audited that channel, now treat those processors as untrusted, and fixed 13 places where values the modem controls could steer the kernel's memory accesses, copy lengths or array indices. A compromised modem can no longer use the channel to read or write arbitrary kernel memory.

Who needs to act

Nobody. All three changes are part of the Foundation OS that every OhrTech device runs.

Engineers who want more technical detail can ask us directly through the engineering contact.

Credit

Both flaws were found by 0x50594d and published by SSD Secure Disclosure. Thank you for the careful research and the public write-ups. Weakness classes: CWE-674 (uncontrolled recursion) and CWE-1189 (improper isolation of shared resources on a system-on-chip).

OHR-2026-006: October 2026 Android security update: applied October 8

Thu, 08 Oct 2026 13:01:00 GMT

Summary

Google's October 2026 Android Security Bulletin fixes 25 vulnerabilities in Android's framework and system components, at security patch level 2026-10-01. We merged the fixes into the Foundation OS on October 8, 2026, the day Google published the source, and built and tested them the same day. Every Foundation OS release since then includes them.

There were no kernel or chip-vendor fixes in this month's bulletin. Google reports no exploitation of any of these issues, and we have no evidence that any were exploited on OhrTech devices.

Fixed, in code that runs on OhrTech devices (16)

Bluetooth: CVE-2026-55269, CVE-2026-58835 and CVE-2026-58880 (Critical, escalation of privilege); CVE-2026-49933 (Critical, denial of service)
Framework: CVE-2026-58865 (Critical, denial of service); CVE-2026-58841 (High); CVE-2026-58834 (High)
Media and camera: CVE-2026-58815 and CVE-2026-58856 (High)
Telephony: CVE-2026-55270 and CVE-2026-58859 (High)
Wi-Fi: CVE-2026-49878 and CVE-2026-45524 (High)
System libraries: CVE-2026-45516 (FreeType), CVE-2026-49937 and CVE-2026-55279 (High)

Fixed, but not reachable on OhrTech devices (8)

We applied these fixes too, but the affected code cannot run on our devices:

NFC: CVE-2026-55280 (Critical), CVE-2026-45513, CVE-2026-49880, CVE-2026-49885 and CVE-2026-28667. OhrTech devices have no NFC hardware, so the NFC service never runs.
ST NFC driver: CVE-2026-55286. This driver is not part of the Foundation OS.
Media tuner service: CVE-2026-58854. There is no tuner hardware, so the service never runs.
libufdt: CVE-2026-55266. This is a build tool and does not run on the device.

Not independently verified (1)

CVE-2026-55265 (Critical, denial of service). Google has not published the source change for this issue, so we cannot confirm the fix in our own source. OhrTech devices are at security patch level 2026-10-01, which Google says addresses it.

Was anything exploitable on OhrTech devices?

Until the update, yes, potentially. The 16 issues in the first list were in code that runs on our devices, and four of them are critical Bluetooth flaws. Verified boot and SELinux limit what an attacker could gain from one of these bugs, but they do not make the bugs impossible to exploit. That is why the fixes went in as soon as Google published them.

We know of no exploitation of these issues on OhrTech devices, and Google's bulletin reports none.

Who needs to act

Nobody. The fixes are part of every Foundation OS release since October 8. If you approve updates manually, make sure your devices have taken the current release.