avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • December 09, 2019, 02:22 AM
  • Proudly celebrating 13 years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: Samsung UEFI/Bricking Bug Update - It's not just Linux  (Read 1933 times)


  • Supporting Member
  • Joined in 2007
  • **
  • Posts: 11,796
    • View Profile
    • Donate to Member
Samsung UEFI/Bricking Bug Update - It's not just Linux
« on: February 11, 2013, 08:08 AM »
From H-Open comes this update on the Samsung laptop bricking issue with some Linux distros. (Article can be found here.)

Samsung UEFI bug: Notebook bricked from Windows

Linux developer Matthew Garrett, who does a lot of research into UEFI topics, writes in a blog post that by storing a large amount of data in UEFI variables, he managed to disrupt a Samsung notebook running Windows to such a degree that it subsequently refused to start. In his post, the developer also points to some sample code of the Windows program that he executed at administrator level to disable the notebook. The developer had previously speculated that some Samsung notebooks with UEFI firmware may be rendered inoperative under Windows in the same way that they were when starting Linux under certain circumstances. The experiment to confirm this was successful.

UEFI variables enable operating systems to deposit data for the firmware that will still be available after a reboot. Microsoft's Windows 8 Hardware Certification Requirements stipulate that at least 64KB of storage must be available for this purpose. When a crash occurs in certain configurations, the Linux kernel uses this storage to deposit information that allows the cause of the crash to be investigated later; Linux places about 10KB of data in a UEFI variable for such a "crash dump". According to Garrett's analysis, this is the actual reason why some Linux distributions destroy Samsung notebooks. The samsung-laptop driver that was previously considered to be the main cause of the disruptions only contributes to the problem through the way it works on UEFI systems: it causes the crash which results in a crash dump being written. How large an amount of data is required to cause firmware malfunction remains unknown; Garrett says that he generated 36 one-kilobyte variables in the tests that resulted in a notebook being disabled under Windows.

The developer concludes that the problem is caused by a firmware flaw. "Writing UEFI variables is expressly permitted by the specification, and there should never be a situation in which an OS can fill the variable store in such a way that the firmware refuses to boot the system", says Garrett. He notes that similar bugs were seen in Intel's reference code for UEFI firmware a year ago, but adds that these bugs have all been fixed. Garrett has renewed his recommendation not to use Windows in UEFI mode on the affected devices. In a subsequent tweet, the developer pointed out that not even removing the CMOS buffer battery brought the device back to life.

Developer Matt Garret's blog post explaining how he did it can be found


Note: Looks like fellow DoCoer f0dder pegged it earlier in this post:

40hz: wrt. the bricking, shouldn't you blame Samsung? Or blame the linux kernel driver developer? I can fry my BIOS/UEFI by flashing it with garbage, who should I blame for that? :-).

Nailed it, I'd say! :Thmbsup:

« Last Edit: February 11, 2013, 08:15 AM by 40hz »


  • Charter Honorary Member
  • Joined in 2005
  • ***
  • Posts: 9,146
  • [Well, THAT escalated quickly!]
    • View Profile
    • f0dder's place
    • Read more about this member.
    • Donate to Member
Re: Samsung UEFI/Bricking Bug Update - It's not just Linux
« Reply #1 on: February 11, 2013, 10:46 AM »
Mentioned here as well, but not very prominently - and it deserves it's own topic anyway :)

One has to wonder wtf Samsung have been smoking to get a firmware-bricking bug that (current guesses) seems to be caused by diagnostic logs that are within the official bounds.
- carpe noctem
« Last Edit: February 11, 2013, 10:51 AM by f0dder »