DEV Community: NewLine Break

A software update should not be able to stop the fridge

NewLine Break — Tue, 06 Oct 2026 18:00:21 +0000

On 22 September 2026 a software update that was still being tested reached Samsung refrigerators in customers' homes in Korea. Owners reported that theirs went dark and stopped cooling. Any team that ships updates can ship a bad one. This note is about how far a bad one should be able to get.

What happened

Samsung's notice to its Korean customers on 23 September says that an error occurred the day before, during the testing of a refrigerator software update, and that some customers' refrigerators showed abnormal symptoms in their power and screen. The company told Ars Technica that the issue was limited to Korea and that it suspended the testing as soon as reports came in.

The Chosun Daily names the line, Bespoke AI 4-Door, and what owners saw after updating through SmartThings: interior lights off, cooling lost, the refrigerator shown as offline. The paper reports that Samsung found the update "was incorrectly distributed to some customers during testing", halted the distribution, and will repair the units free of charge. Owners wrote that technicians replaced the main board, Android Authority reports.

Samsung has not said three things: how many units, how an update in testing reached customers, and what failed inside. We do not know how these refrigerators are built, and this note does not guess. What the reports describe is an outcome in four steps. An update still in testing was installed in a kitchen. Owners say the appliance's main job stopped with it. The remedy in Samsung's notice was a call to the service centre and a technician's visit. And it reached enough homes that, according to Ars Technica, the broadcaster SBS reported hundreds of cases. Each step is something a design can guard against.

Four things an update path should guard against

1. A build still in testing installs on a customer's unit

Let the device decide, not the server. Sign test builds with one key and releases with another, and give the units that leave the factory only the release key. A test-signed build sent down the wrong channel then ends as a refused image. A release candidate carries the release key, so it still needs the stages below. Keep the test units as a named fleet of their own, so that "all units" never includes them by accident, or the other way round.

Even the basic check, that an image is genuine, is not a given. A Moxa advisory of 2 October describes protocol gateways that do not properly verify the authenticity of a firmware image before installing it.

2. An update stops the main job

Whatever a device's one job is (cooling, heating, dosing, locking a door), give it a controller of its own that keeps its own settings, with firmware that changes rarely, and let the connected side ask it for things instead of running it. Then the part that takes an update every month can hang, restart or sit half written while the main job keeps its schedule. This is decided on the schematic before it is decided in code: which processor switches the load.

3. A unit does not come back by itself

Write the new image to a second slot and start it on trial. If it does not mark itself as good, the bootloader returns to the old image at the next reset. MCUboot, an open source bootloader for microcontrollers, calls this a test swap, and says it is there "to prevent devices from becoming 'bricked' by bad firmware". Three details decide whether it works. Good has to mean that the job is being done (the sensors read, the controller answers), not that the image started. An image that has not marked itself good within a set time has to reset. And a watchdog, running before the new image starts, has to force the reset when the image hangs instead of crashing.

4. A bad build reaches everyone at once

Release in stages: your own units, then a small share of the field, then the rest, with a wait between stages. Have every unit report in after an update, and let the rollout stop by itself when updated units go quiet. A rollout that watches its own units can stop before the first customer has to write.

What went right

One part of Samsung's response is worth copying. According to The Chosun Daily, it plans to find the affected customers from the update history. A record of which unit took which build, and when, turns "some customers' refrigerators" into a list of units. It is the first question in our note on the Cyber Resilience Act, and the third question there, whether a fix can reach the units, is this note seen from the other side.

A drill for the bench

Three tests on the bench, through your real update path. Send a test unit an image that starts and then does nothing: does the unit come back by itself, and does its main job run the whole time? Cut the power while an image is being written, and again while the bootloader is swapping it in. Then offer a production unit a build signed with the test key. What happens in each case shows how far a bad update can get on one unit.

Sources

Samsung Members: notice on the refrigerator software error (23 September 2026, in Korean)
Ars Technica: Owners mourn spoiled food after firmware update bricks Samsung smart fridges (23 September 2026, updated 24 September with Samsung's statement)
The Chosun Daily: Samsung Refrigerators Fail After Update, Repairs During Chuseok (23 September 2026)
Android Authority: Samsung accidentally freezes its smart fridges with a software update (23 September 2026)
Moxa security advisory MPSA-269540, CVE-2026-86326 (2 October 2026)
MCUboot: bootloader design, the section on boot swap types

All notes

First published at newlinebreak.com/notes/update-that-stopped-the-fridge.

Cyber Resilience Act: what your devices should be able to tell you

NewLine Break — Tue, 06 Oct 2026 06:13:27 +0000

Since 11 September 2026, a manufacturer that learns one of its connected products is being attacked through a flaw has at most 24 hours to send an early warning. That warning is short. The notification due two days later is not, and most of it can only be answered if the device and the system behind it can tell you.

What changed on 11 September

Article 14 of the EU's Cyber Resilience Act, the manufacturer's reporting duty, applies from that date. Most of the rest of the regulation follows on 11 December 2027 (Article 71). The Commission's summary gives the clock for a vulnerability that is being actively exploited:

24 hours: An early warning, counted from the moment the manufacturer becomes aware.
72 hours: A fuller notification.
14 days: A final report, counted from the day a fix or a mitigation is available.

A severe incident runs on the same first two steps, with its final report due a month after the notification. Everything is filed once, through ENISA's Single Reporting Platform.

Article 69(3) says the duty covers products placed on the market before December 2027. If a product is in scope, that includes units shipped three years ago.

Whether a product is in scope, and who is its manufacturer, is a question for a lawyer. This note is about the engineering.

What the reports ask for

Article 14 reads like a list of questions. The early warning names the Member States where the product is known to be available. The notification gives general information about the product, the nature of the exploit and of the vulnerability, what has been done about it, and what users can do. The final report describes the vulnerability with its severity and impact, who exploited it where that is known, and the update that fixes it. Paragraph 8 adds one more job: tell the users who are affected.

None of this is hard to write down. All of it is hard to know in three days, unless the product was built to tell you.

Four things the device should be able to answer

1. Which units run the affected code

Give every build an identity: a version and the commit it was built from, compiled into the image and readable over the wire. Have every unit report the build it runs and its hardware revision. Keep, for each build, the list of what is in it and how it was configured: bootloader, RTOS, TLS library, radio stack, each with its version and its build options.

The regulation asks for that list as a software bill of materials from December 2027 (Annex I, Part II). It is needed sooner: it is what turns "there is a flaw in this library" into a list of serial numbers.

A test from last week: CVE-2026-71973, published on 29 September, is an integer overflow in the SquashFS reader of the U-Boot bootloader, in versions before 2026.10-rc4. Its record describes an out-of-bounds heap write from a crafted image and no known attacks, so on that record it is not "actively exploited" as the regulation defines it. It is still a good question to practise on. SquashFS support is a build option in U-Boot. How long would it take to say which of your units carry a U-Boot built with it?

2. Where they went

The early warning names countries. A device does not know its country. The shipping record does. When a unit leaves for a customer, record who it went to and which country, against its serial number. If it is sold through distributors, record the distributor and its market.

3. Whether a fix can reach them

The update path has to exist before the problem does: signed images, a version floor so that a fixed unit cannot be put back on the old build, a second slot to fall back to, a rollout that can be staged and stopped. Check what the path covers: on many boards it updates the application and never the bootloader. Know which units have not checked in, and for how long. Send a harmless update through it on a schedule, so its first real use is not its first use.

4. What users can do until then

The notification asks for measures users can take. Decide now what they are: a service that can be switched off remotely, a port closed by configuration, an instruction that fits in two lines. Keep a way to reach users that does not depend on the broken feature.

How you would find out

The clock starts when the manufacturer becomes aware. The Commission's guidance reads that as the point where, after a first assessment, the manufacturer is reasonably certain that a flaw in its product is being exploited. The first sign arrives in three ways. Someone tells you: publish a security contact, usually a security.txt file. Your telemetry shows it: have devices report resets, failed updates and rejected signatures. Or a component you ship gets an advisory that reports attacks: watch the advisories for every entry on the list from point 1.

Not every flaw starts the clock. The regulation's word is "actively exploited": there is reliable evidence that an attacker has used the flaw against a system without its owner's permission (Article 3).

A drill for this week

Pick one component in your current firmware. Assume a flaw in it is being used against your product, and start a timer. Which units. Which countries. Can a fix reach them. What do users do meanwhile. Whatever cannot be answered within the hour is the work list.

Sources

European Commission: CRA reporting obligations (11 September 2026)
Regulation (EU) 2024/2847, Articles 3, 14, 69 and 71, Annex I
European Commission: CRA guidance, Section 9.1
ENISA: The CRA Single Reporting Platform is launched (11 September 2026)
NVD: CVE-2026-71973 (published 29 September 2026)
U-Boot: fs/squashfs/Kconfig
RFC 9116: security.txt

First published at newlinebreak.com/notes/cyber-resilience-act-24-hours.