This has been a commonplace feature on SOCs for a decade or two now. The comments seem to be taking this headline as out‑of‑the‑ordinary news, phrased as if Oneplus invented it. Even cheapo devices often use an eFuse as anti-rollback. We do it at my work whenever root exploits are found that let you run unsigned code. If we don't blow an eFuse, then those security updates can just be undone, since any random enemy with hardware access could plug in a USB cable, flash the older exploitable signed firmware, steal your personal data, install a trojan, etc. I get the appeal of ROMs/jailbreaking/piracy but it relies on running obsolete exploitable firmware. It's not like they're forcing anyone to install the security patch who doesn't want it. This is normal.
According to OP this does not disable bootloader unlocking in itself. It makes the up-versioned devices incompatible with all previous custom ROMs, but it should be possible to develop new ROM releases that are fully compatible with current eFuse states and don't blow the eFuse themselves.
This goes beyond the 'right to repair' to simply the right of ownership. These remote updates prove again and again that even though you paid for something you don't actually own it.
Unfortunately similar things will be mandated by EU law through cyber resiliance act (CRA) in order to ensure tamper free boot of any kind of device sold in the EU from Dec 2027.
Basically breaking any kind of FOSS or repairability, creating dead HW bricks if the vendor ceases to maintain or exist.
What do OnePlus gain from this? Can someone explain me what are the advantages of OnePlus doing all this?
A failed update resulting in motherboard replacement? More money, more shareholders are happy?
I still sometimes ponder if oneplus green line fiasco is a failed hardware fuse type thing that got accidentally triggered during software update. (Insert I can't prove meme here).
I'm not sure if this is the case anymore, but many unbranded/generic Androids used to be completely unlocked by default (especially Mediatek SoCs) and nearly unbrickable, and that's what let the modding scene flourish. I believe they had efuses too, but software never used them.
> When the device powers on, the Primary Boot Loader in the processor's ROM loads and verifies the eXtensible Boot Loader (XBL). XBL reads the current anti-rollback version from the Qfprom fuses and compares it against the firmware's embedded version number. If the firmware version is lower than the fuse value, boot is rejected. When newer firmware successfully boots, the bootloader issues commands through Qualcomm's TrustZone to blow additional fuses, permanently recording the new minimum version
What exactly is it comparing? What is the “firmware embedded version number”? With an unlocked bootloader you can flash boot and super (system, vendor, etc) partitions, but I must be missing something because it seems like this would be bypassable.
It does say
> Custom ROMs package firmware components from the stock firmware they were built against. If a user's device has been updated to a fused firmware version & they flash a custom ROM built against older firmware, the anti-rollback mechanism triggers immediately.
and I know custom ROMs will often say “make sure you flash stock version x.y beforehand” to ensure you’re on the right firmware, but I’m not sure what partitions that actually refers to (and it’s not the same as vendor blobs), or how much work it is to either build a custom ROM against a newer firmware or patch the (hundreds of) vendor blobs.
Blind speculation: I wonder if this is in some way related to DRM getting broken at a firmware level, leading to a choice being made between "users complain that they can't watch netflix" and "users complain that they can't install custom ROMs".
OnePlus has pretty much become irrelevant since Carl Pei left the company. Its more or less just a rebranded Oppo nowadays. I'm not an android user anymore but I'm rooting for his new(ish) Nothing company. Hopefully it carries the torch for the old OnePlus feel.
Does anyone know if it has been confirmed that this only applies to the "ColorOS" branded firmware versions? Because I currently have an update to OxygenOS 16.0.3.501 pending on my OnePlus 15, which is presumably built from the same codebase.
This does not surprise me from the company that accidentally deleted the widevine L1 certificate on my phone (that never had any third party OS) during an update and could not restore it, nor would it replace the motherboard (for which it claimed it was the only possible fix).
Damn, I just saw that update yesterday on my phone and did not update it for no reason. Turned off auto-update right now until I figure out what to do.
If so, is this 'fuse' per-planned in the hardware? My understanding is cell phones take 12 to 24 months from design to market. so, initial deployment of the model where this OS can trigger the 'fuse' less one year is how far back the company decided to be ready to do this?
That's insane. If the CPU has enough fuses (which according to the wiki it does) why the h*ck can't they just make it impossible to reflash the >= minimum previously installed version of the OS after preventing the downgrade? Why the hard brick?
This is industry standard. Flashing old updates that are insecure to bypass security is a legitimate attack vector that needs to be defended against. Ideally it would still be possible up recover from such a scenario by flashing the latest update.
It's Google's fault. I want to buy a smartphone without AVB at all. With no "secure boot" fuse blown (yes I DO know that this is not the same fuse) and ideally I'd want to provision my own keys.
But vendors wouldn't be able to say the device runs "Android" as it's trademarked. AVB is therefore mandatory and in order for AVB to be enforced, you can't really control the device - unlocking the bootloader gives you only partial control, you can't flash your own "abl" to remove AVB entirely.
But I don't want AVB and I can't buy such device for money.. this isn't free market, this is Google monopoly..
Its high time we start challenging these sorts of actions as the "vandalization and sabotage at scale" that these attacks really are. I dont see how these aren't a direct violation of the CFAA, over millions of customer-owned hardware.
They are no different than some shit ransomware, except there is no demand for money. However, there is a demonstrable proof of degradation and destruction of property in all these choices.
Frankly, criminal AND civil penalties should be levied. Criminally, the C levels and boars of directors should all be in scope as to encouraging/allowing/requiring this behavior. RICO act as well, since this smells like a criminal conspiracy. Let them spend time in prison for mass destruction of property.
Civally, start dissolving assets until the people are made whole with unbroken (and un-destroyed) hardware.
The next shitty silly-con valley company thinks about running this scam of 'customer-bought but forever company owned', will think long and hard about the choices of their network and cloud.
This is absolutely cracked. I've been with OnePlus since the One, also getting the 2, 6 and now I have the 12. Stuck with them all these years because I really respected their - original - take on device freedom. I really should've seen the writing on the wall given how much pain it is to update it in the first place, as I have the NA version which only officially allows carrier updates, and I don't live in NA (and even if I did I'd still not be tied to a carrier).
Now I have to consider my device dead re updates, because if I haven't already gotten the killing update I'd rather avoid it. First thing I did was unlock the bootloader, and I intend to root/flash it at some point. Will be finding another brand whenever I'm ready to upgrade again.
Oneplus phone update introduces hardware anti-rollback
(consumerrights.wiki)458 points by validatori 25 January 2026 | 270 comments
Comments
> The anti-rollback mechanism uses Qfprom (Qualcomm Fuse Programmable Read-Only Memory), a region on Qualcomm processors containing one-time programmable electronic fuses.
What a nice thoughtful people to build such a feature.
That’s why you sanction the hell out of Chinese Loongson or Russian Baikal pity of CPU — harder to disable than programmatically “blowing a fuse”.
Basically breaking any kind of FOSS or repairability, creating dead HW bricks if the vendor ceases to maintain or exist.
I still sometimes ponder if oneplus green line fiasco is a failed hardware fuse type thing that got accidentally triggered during software update. (Insert I can't prove meme here).
What exactly is it comparing? What is the “firmware embedded version number”? With an unlocked bootloader you can flash boot and super (system, vendor, etc) partitions, but I must be missing something because it seems like this would be bypassable.
It does say
> Custom ROMs package firmware components from the stock firmware they were built against. If a user's device has been updated to a fused firmware version & they flash a custom ROM built against older firmware, the anti-rollback mechanism triggers immediately.
and I know custom ROMs will often say “make sure you flash stock version x.y beforehand” to ensure you’re on the right firmware, but I’m not sure what partitions that actually refers to (and it’s not the same as vendor blobs), or how much work it is to either build a custom ROM against a newer firmware or patch the (hundreds of) vendor blobs.
Edit: It seems that this does apply to OxygenOS too: https://xdaforums.com/t/critical-warning-coloros-16-0-3-501-...
If so, is this 'fuse' per-planned in the hardware? My understanding is cell phones take 12 to 24 months from design to market. so, initial deployment of the model where this OS can trigger the 'fuse' less one year is how far back the company decided to be ready to do this?
This is ultimately about making the device resistant to downgrade attacks. This is what discourages thieves from stealing your phone.
https://news.ycombinator.com/item?id=30773214
But vendors wouldn't be able to say the device runs "Android" as it's trademarked. AVB is therefore mandatory and in order for AVB to be enforced, you can't really control the device - unlocking the bootloader gives you only partial control, you can't flash your own "abl" to remove AVB entirely.
But I don't want AVB and I can't buy such device for money.. this isn't free market, this is Google monopoly..
They are no different than some shit ransomware, except there is no demand for money. However, there is a demonstrable proof of degradation and destruction of property in all these choices.
Frankly, criminal AND civil penalties should be levied. Criminally, the C levels and boars of directors should all be in scope as to encouraging/allowing/requiring this behavior. RICO act as well, since this smells like a criminal conspiracy. Let them spend time in prison for mass destruction of property.
Civally, start dissolving assets until the people are made whole with unbroken (and un-destroyed) hardware.
The next shitty silly-con valley company thinks about running this scam of 'customer-bought but forever company owned', will think long and hard about the choices of their network and cloud.
Now I have to consider my device dead re updates, because if I haven't already gotten the killing update I'd rather avoid it. First thing I did was unlock the bootloader, and I intend to root/flash it at some point. Will be finding another brand whenever I'm ready to upgrade again.