lix-project/lix

Fork 48

crash when parsing large binary numbers using `builtins.fromTOML` #914

New issue

Open

opened 2025-07-12 10:59:15 +00:00 by w-lfchen · 6 comments

w-lfchen commented

2025-07-12 10:59:15 +00:00

Describe the bug

evaluating builtins.fromTOML terminates evaluation with sigill if given a binary number that is sufficiently long (>62 digits).

Steps To Reproduce

evaluate the following expression (e.g., in the repl):

builtins.fromTOML "v=0b000000000000000000000000000000000000000000000000000000000000000"

(whether the value contains 1's or 0's doesn't matter)

Expected behavior

the number should be parsed correctly, and lix shouldn't crash. the result should be an attribute set {v = 0;}

`nix --version` output

nix (Lix, like Nix) 2.93.2
System type: x86_64-linux
Additional system types: i686-linux, x86_64-v1-linux, x86_64-v2-linux, x86_64-v3-linux
Features: gc, signed-caches
System configuration file: /etc/nix/nix.conf
User configuration files: /home/wolf/.config/nix/nix.conf:/etc/xdg/nix/nix.conf:/home/wolf/.nix-profile/etc/xdg/nix/nix.conf:/nix/profile/etc/xdg/nix/nix.conf:/home/wolf/.local/state/nix/profile/etc/xdg/nix/nix.conf:/etc/profiles/per-user/wolf/etc/xdg/nix/nix.conf:/nix/var/nix/profiles/default/etc/xdg/nix/nix.conf:/run/current-system/sw/etc/xdg/nix/nix.conf
Store directory: /nix/store
State directory: /nix/var/nix
Data directory: /nix/store/v1qd5dx8bwx6k591yj53w2y96l9b3dhl-lix-2.93.2/share

Additional context

this bug is not present in cppnix 2.28.4
there seem to be no issues parsing long hexadecimal numbers from my limited testing

## Describe the bug evaluating `builtins.fromTOML` terminates evaluation with sigill if given a binary number that is sufficiently long (>62 digits). ## Steps To Reproduce evaluate the following expression (e.g., in the repl): ```nix builtins.fromTOML "v=0b000000000000000000000000000000000000000000000000000000000000000" ``` (whether the value contains 1's or 0's doesn't matter) ## Expected behavior the number should be parsed correctly, and lix shouldn't crash. the result should be an attribute set `{v = 0;}` ## `nix --version` output ``` nix (Lix, like Nix) 2.93.2 System type: x86_64-linux Additional system types: i686-linux, x86_64-v1-linux, x86_64-v2-linux, x86_64-v3-linux Features: gc, signed-caches System configuration file: /etc/nix/nix.conf User configuration files: /home/wolf/.config/nix/nix.conf:/etc/xdg/nix/nix.conf:/home/wolf/.nix-profile/etc/xdg/nix/nix.conf:/nix/profile/etc/xdg/nix/nix.conf:/home/wolf/.local/state/nix/profile/etc/xdg/nix/nix.conf:/etc/profiles/per-user/wolf/etc/xdg/nix/nix.conf:/nix/var/nix/profiles/default/etc/xdg/nix/nix.conf:/run/current-system/sw/etc/xdg/nix/nix.conf Store directory: /nix/store State directory: /nix/var/nix Data directory: /nix/store/v1qd5dx8bwx6k591yj53w2y96l9b3dhl-lix-2.93.2/share ``` ## Additional context - this bug is not present in cppnix 2.28.4 - there seem to be no issues parsing long hexadecimal numbers from my limited testing

w-lfchen added the

bug

label

2025-07-12 10:59:15 +00:00

pennae commented

2025-07-12 18:26:32 +00:00

Owner

that's undefined behavior in toml11, with theirs report matching this problem two years ago: https://github.com/ToruNiina/toml11/issues/213. we catch it because we run -fsanitize=undefined in prod to avoid weird shit happening (as was prevented in this case! cppnix produces { v = -9223372036854775808; } for v=0b1000000000000000000000000000000000000000000000000000000000000000, which is obviously nonsense. add another 0 to the binary literal and you get { v = 0; } instead, which is even worse)

nixpkgs really ought to upgrade toml11. (keeping this bug open because we could in theory override the dependency with a newer version to fix this)

that's undefined behavior in toml11, with theirs report matching this problem two years ago: https://github.com/ToruNiina/toml11/issues/213. we catch it because we run `-fsanitize=undefined` in prod to avoid weird shit happening (as was prevented in this case! cppnix produces `{ v = -9223372036854775808; }` for `v=0b1000000000000000000000000000000000000000000000000000000000000000`, which is obviously nonsense. add another `0` to the binary literal and you get `{ v = 0; }` instead, which is even worse) nixpkgs really ought to upgrade toml11. (keeping this bug open because we could in theory override the dependency with a newer version to fix this)

w-lfchen commented

2025-07-13 10:01:13 +00:00

Author

thank you so much for the quick and informative response! <3
do i understand it correctly that providing some sort of error message is therefore not an option as toml11 handles the parsing?

thank you so much for the quick and informative response! <3 do i understand it correctly that providing some sort of error message is therefore not an option as toml11 handles the parsing?

pennae commented

2025-07-13 11:19:25 +00:00

Owner

unfortunately yes. our hardening compiler options cause the program to crash hard the moment a problem is detected. in theory the crash is detectable to us, but at that point the program is in a state where we can no longer give reasonable error message to the user (let alone know what caused the crash in the first place) :(

unfortunately yes. our hardening compiler options cause the program to crash *hard* the moment a problem is detected. in theory the crash is detectable to us, but at that point the program is in a state where we can no longer give reasonable error message to the user (let alone know what caused the crash in the first place) :(

w-lfchen commented

2025-07-13 13:56:35 +00:00

Author

makes sense.
toml11 has no maintainers since november of last year (and its version was never updated anyways), i think i'll look into updating/adopting it as the derivation seems pretty simple even to me as a novice on this field ^^

makes sense. toml11 has no maintainers since [november of last year](https://github.com/NixOS/nixpkgs/commit/4cf85b6e2cb3ac01d7b86bf643e4c7639acca422) (and its version was never updated anyways), i think i'll look into updating/adopting it as the derivation seems pretty simple even to me as a novice on this field ^^

❤️ 1

w-lfchen commented

2025-07-13 16:55:03 +00:00

Author

just thought this might be worth to mention, as lix will probably break as well once toml11 4.4.0 is in nixpkgs so it might be worthwhile to override it to not get some surprise breakages down the road, though i don't know anything about the build/development process of lix
don't really know what else to say, but i don't think i can help out much here unfortunately, sorry :(

from what i gathered, https://github.com/NixOS/nixpkgs/pull/394444 will update toml11 as well and i don't know whether i want to file a pr that breaks building nix itself (most likely due to breaking changes in toml11 4.0.0) since i probably lack the expertise to fix that (i know very little c++) and someone else should be investigating: https://github.com/NixOS/nixpkgs/pull/363466 just thought this might be worth to mention, as lix will probably break as well once toml11 4.4.0 is in nixpkgs so it might be worthwhile to override it to not get some surprise breakages down the road, though i don't know anything about the build/development process of lix don't really know what else to say, but i don't think i can help out much here unfortunately, sorry :(

pennae commented

2025-07-13 17:12:02 +00:00

Owner

that's okay. somefew will get around to it eventually :)

❤️ 1