Microsoft Surface Flaw Allowed Unprotected Devices To Be Bricked By a Single Packet
(Friday June 12, 2026 @05:20PM (BeauHD)
from the mostly-fixed dept.)
- Reference: 0183770908
- News link: https://it.slashdot.org/story/26/06/12/1755225/microsoft-surface-flaw-allowed-unprotected-devices-to-be-bricked-by-a-single-packet
- Source link:
Longtime Slashdot reader [1]Dotnaught shares a report from The Register:
> For the past 90 days, Microsoft has been [2]quietly patching a firmware flaw in Surface devices that allowed the hardware to be bricked with a single packet, though only for those who have disabled Secure Core and Secure Boot. And the company's Copilot AI software inadvertently helped identify the faulty firmware.
>
> According to Jack Darcy, a security researcher based in Australia, his instance of Microsoft Copilot stumbled across the bug after being asked to adjust the screen backlighting on a Surface device. The Copilot-conjured Python script ended up rendering the researcher's laptop inoperable by overwriting the embedded controller firmware. "Copilot autonomously created and executed four progressively aggressive Python scripts during a probe for backlight control values that sent raw [3]SSAM ioctl commands (SSAM_CDEV_REQUEST = 0xC028A501) directly to the SAM microcontroller through the SAM software path," Darcy explained to The Register.
>
> [...] "We appreciate the work of Jack Darcy and The Register for reporting this issue under a coordinated vulnerability disclosure," a Microsoft spokesperson said in a statement. "Our investigation found that a deprecated UEFI interface could trigger a boot loop on some devices. To trigger this loop, the user must have administrator privileges and have already disabled the Secure Boot security feature. We have released updates to address the issue for most impacted devices."
>
> That means managed devices are not at risk. But those using Linux, or Windows users who have disabled Secure Core and Secure Boot for gaming, or who use custom Windows drivers, or who have USB boot enabled, may still be vulnerable if their systems haven't received the update. We're uncertain about the range of Surface devices affected. Our source said it appears to be all of them (Surface Laptops 3-6, Surface Book 1-3) except for Surface Go models. ARM variants, however, have not been tested.
The report notes that Microsoft is planning to move the Surface stack to a more secure architecture based on Rust code.
"Our most recent Surface for Business hardware features a major architectural shift in terms of improved reliability and security that spans our embedded controller, UEFI, but also some of our drivers," said David Abzarian, chief architect for Microsoft Surface. "We're investing in the most secure foundation for a PC by building our embedded controller firmware from the ground up in Rust (as part of leveraging and contributing to the Open Device Partnership (ODP)) in addition to a rewrite of the UEFI DXE Core in Rust; these projects are known as Secure EC and Project Patina respectively."
"We're also not only shipping some of our drivers written in Rust, but also helping co-develop the framework Windows Drivers in Rust (WDR) to help enable a broad set of partners in the Windows ecosystem to capitalize on these benefits. I will also note that all of these efforts are open-source promoting one of our key security principles around transparency."
[1] https://slashdot.org/~Dotnaught
[2] https://www.theregister.com/security/2026/06/12/microsoft-has-mostly-repaired-a-flaw-in-surface-hardware-that-allowed-unprotected-devices-to-be-bricked-by-a-single-packet/5253895
[3] https://docs.kernel.org/driver-api/surface_aggregator/overview.html
> For the past 90 days, Microsoft has been [2]quietly patching a firmware flaw in Surface devices that allowed the hardware to be bricked with a single packet, though only for those who have disabled Secure Core and Secure Boot. And the company's Copilot AI software inadvertently helped identify the faulty firmware.
>
> According to Jack Darcy, a security researcher based in Australia, his instance of Microsoft Copilot stumbled across the bug after being asked to adjust the screen backlighting on a Surface device. The Copilot-conjured Python script ended up rendering the researcher's laptop inoperable by overwriting the embedded controller firmware. "Copilot autonomously created and executed four progressively aggressive Python scripts during a probe for backlight control values that sent raw [3]SSAM ioctl commands (SSAM_CDEV_REQUEST = 0xC028A501) directly to the SAM microcontroller through the SAM software path," Darcy explained to The Register.
>
> [...] "We appreciate the work of Jack Darcy and The Register for reporting this issue under a coordinated vulnerability disclosure," a Microsoft spokesperson said in a statement. "Our investigation found that a deprecated UEFI interface could trigger a boot loop on some devices. To trigger this loop, the user must have administrator privileges and have already disabled the Secure Boot security feature. We have released updates to address the issue for most impacted devices."
>
> That means managed devices are not at risk. But those using Linux, or Windows users who have disabled Secure Core and Secure Boot for gaming, or who use custom Windows drivers, or who have USB boot enabled, may still be vulnerable if their systems haven't received the update. We're uncertain about the range of Surface devices affected. Our source said it appears to be all of them (Surface Laptops 3-6, Surface Book 1-3) except for Surface Go models. ARM variants, however, have not been tested.
The report notes that Microsoft is planning to move the Surface stack to a more secure architecture based on Rust code.
"Our most recent Surface for Business hardware features a major architectural shift in terms of improved reliability and security that spans our embedded controller, UEFI, but also some of our drivers," said David Abzarian, chief architect for Microsoft Surface. "We're investing in the most secure foundation for a PC by building our embedded controller firmware from the ground up in Rust (as part of leveraging and contributing to the Open Device Partnership (ODP)) in addition to a rewrite of the UEFI DXE Core in Rust; these projects are known as Secure EC and Project Patina respectively."
"We're also not only shipping some of our drivers written in Rust, but also helping co-develop the framework Windows Drivers in Rust (WDR) to help enable a broad set of partners in the Windows ecosystem to capitalize on these benefits. I will also note that all of these efforts are open-source promoting one of our key security principles around transparency."
[1] https://slashdot.org/~Dotnaught
[2] https://www.theregister.com/security/2026/06/12/microsoft-has-mostly-repaired-a-flaw-in-surface-hardware-that-allowed-unprotected-devices-to-be-bricked-by-a-single-packet/5253895
[3] https://docs.kernel.org/driver-api/surface_aggregator/overview.html
planning to move to rust (Score:2)
by toxonix ( 1793960 )
"The report notes that Microsoft is planning to move the Surface stack to a more secure architecture based on Rust code."
Aren't we all? Planning. To (have Claude) migrate everything to Rust.
"these projects are known as Secure EC and Project Patina respectively."
Ah I get it. Patina -> rust. clever.
Killer Poke (Score:5, Funny)
by jpatters ( 883 )
POKE 59458,62
Does this really affect anyone? (Score:1)
by supabeast! ( 84658 )
If this is only going to affect devices that have Secure Core and Secure Boot enabled how many devices like that exist in the wild? Who would disable both of those other than a handful of developers trying to make Linux work on Surface computers and security researchers who want to break their stuff?
Re: (Score:2)
by omnichad ( 1198475 )
I don't think this article is interesting because a flaw was discovered. It was over how stupidly Copilot handled the assignment.
Raises hand ... (Score:2)
by fahrbot-bot ( 874524 )
I'm not much of a laptop user, and haven't seen many Surface devices, but all the laptops I've seen have functions keys to adjust the screen brightness. Is this something different or doesn't Surface have some tactile way to accomplish this?
Amazing... (Score:3)
In a sane world, you might expect the Windows 'integrated' AI to be wired up to just... adjust the brightness..
But *fine*, you don't wire it up, you might then at least hope the AI to say "That capability is not enabled, but here is some help text telling you to do it".
But nope, "That sounds like something an ioctl would do, and I don't know the ioctl per se, but let's just submit random bullshit ioctls and *maybe* it will happen to do as user requested?"
Re:Amazing... (Score:4, Interesting)
Just for fun, I asked Gemini and it says:
> To adjust the screen brightness on a Microsoft Surface (or any Windows laptop), you can use the WMI API (Windows Management Instrumentation) with WmiMonitorBrightnessMethods or the UWP BrightnessOverride class.
>> So yeah, it's wild how these LLMs lose the plot and just start bashing square pegs into round holes.
Re: (Score:2)
Though an LLM might have gotten my closing
Re: (Score:2)
I love how it's so blatantly obvious that they are leaning into software development and the models are assuming you are going to write some C# to adjust brightness.
No idea if that's even close to right and I'm not inclined to check, but the fact the first answer is not "Well, find the brightness buttons and press them" is telling.