Readit NewsIt seems crazy to me that vulnerabilities like this still exist today. I understand that not everything will be written in Rust, but this could have been caught by basic testing and/or fuzzing, as Nick (the person who found the vulnerability) points out: https://www.openwall.com/lists/musl/2025/02/14/1. So far, this earned an 8.1 from MITRE: https://nvd.nist.gov/vuln/detail/CVE-2025-26519, although I'm not sure if that's just a function of it being a bug in a library that so many applications use.
This also goes to show how every line matters. The one line change was from
if (c >= 93 || c>=0xc6-0x81 && d>0x52)
if (c > 0xc6-0x81 || c==0xc6-0x81 && d>0x52)
To explain the bug, EUC_KR is Extended Unicode - Korean. After ASCII characters (0-127), each character is multiple bytes. The logic adjusts to look up from a base-0 index, then checks that both bytes (variables c and d) are in the normalized range. If not, the code adjusts the characters and checks the bounds again. This second check is what contained the bug.
0xc6 - 0x81 is the upper bound of this check (69), not 93. The irony is that the second part of the check gets this correct. I wonder what a `git blame` would reveal about this particular line.
pbrowne011 commented on What's New in Emacs 30.1? masteringemacs.org/articl... · Posted by u/trocado
Fun to see someone decide to just write a faster JSON parser because they believed it was possible. They mentioned last year that libjansson had some intermediate layer with Emacs, which led to too many memory allocations: https://lists.gnu.org/archive/html/emacs-devel/2024-03/msg00...
Also, the developer who wrote the parser (Géza Herman) was able to pass all of the tests with strange edge cases from https://seriot.ch/projects/parsing_json.html very quickly: https://lists.gnu.org/archive/html/emacs-devel/2024-03/msg00...
pbrowne011 commented on Defragging my old Dell's UEFI NVRAM artemis.sh/2025/02/22/uef... · Posted by u/todsacerdoti
There's also the fact that an NVRAM variable is never overwritten inplace; the new value is written elsewhere, and the pointer is updated to use the address of the new value. This is probably mainly for wear-leveling, but I guess it could also introduce fragmentation?
Just an observation from when I was debugging a board that selfdestructed when booting a particular efi-file so I had to dig into the flash contents to figure out why, but I think this particular code was straight from tianocore.
True, I was trying to find the variable storage requirements in the UEFI specification but couldn't (is it Section 3? 8?), so I resorted to linking to the struct definition in the EFI shell package that the author used.
pbrowne011 commented on Defragging my old Dell's UEFI NVRAM artemis.sh/2025/02/22/uef... · Posted by u/todsacerdoti
Very interesting. I wonder if this a result of some "swiss cheese" effect due to constraints around UEFI and NVRAM themselves, when updating EFI variables.
NVRAM must maintain atomicity of memory transactions for power failures. Its whole purpose is to store data when you turn your computer off. As a result, when deleteing an EFI variable, you can't manage the individual bytes - you have to delete a whole entry (which can be rather large - based on the EFI specification and the code used for edk2, e.g. https://github.com/tianocore/edk2/blob/83a86f465ccb1a792f5c5...). Deleting these entries might become a problem when you start running against memory constraints and what slots in memory are actually available; hence a possible fragmentation issue.
Additionally, I appreciated how short and specific this blog post was. I enjoy this style of post of someone encountering a problem and solving it.
X (Twitter): https://x.com/I4Replication/status/1893842119594258913
Bluesky: https://bsky.app/profile/i4replication.bsky.social/post/3liv...