-
-
Notifications
You must be signed in to change notification settings - Fork 6.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integer Overflow (OSS-Fuzz 12506) #1447
Comments
The same input also triggered this issue:
Details:
|
I can reproduce the issue. Line abs_value = static_cast<number_unsigned_t>(0 - x); Yields the message:
|
@nickaein Any ideas on this? |
I think that when Fix is easy, change
to
should do. |
Doesn't that assume 2's complement signed integers? abs_value = static_cast<number_unsigned_t>(-1 - x) + 1; is a bit more portable, and works since this code only runs when x < 0. That said, I don't know of any CPUs using 1's complement for signed integers, so I'm not sure it matters. |
Thanks @smonkewitz ! |
(Also thanks @scinart !) |
Both issues have been reported and confirmed fixed by OSS-Fuzz. |
Hi - this: Your fix that assumes 2's complement is the correct fix, since unsigned overflow is defined by the standard, and the compiler isn't going to throw it out. |
Two's complement is the only game in town (P1236 was voted in and even C is adopting similar assumptions). |
Signed overflow is a tough one, as there are demonstrable benefits to it being UB. However, as you say, providing defined behavior has good benefits too, although there are many forms of that (wrap, saturate, throw). I personally hope we get such types in C++ one day (which are not named "int", eg), but we shall see what the Committee does! |
At least for addition, it is practically defined because both signed and unsigned addition use the same assembly instruction. At any rate, happy to have that conversation offline, not relevant to this code, AFAIK.
From: Jared Grubb <notifications@github.com>
Sent: Monday, April 8, 2019 6:07 PM
To: nlohmann/json <json@noreply.github.com>
Cc: David LeBlanc <dleblanc@exchange.microsoft.com>; Comment <comment@noreply.github.com>
Subject: Re: [nlohmann/json] Integer Overflow (OSS-Fuzz 12506) (#1447)
Signed overflow is a tough one, as there are demonstrable benefits to it being UB. However, as you say, providing defined behavior has good benefits too, although there are many forms of that (wrap, saturate, throw). I personally hope we get such types in C++ one day (which are not named "int", eg), but we shall see what the Committee does!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnlohmann%2Fjson%2Fissues%2F1447%23issuecomment-481062337&data=02%7C01%7Cdleblanc%40exchange.microsoft.com%7C8094489204694756b65208d6bc87a1ff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636903688061734930&sdata=n1%2FTMuUvjQZaennXBjWxEz9r9HPUQJu%2FxuMYUBga9yc%3D&reserved=0>, or mute the thread<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAe_sL0WLgayAGn3jKIB5m3WiBP9aw52kks5ve-ekgaJpZM4aJOHZ&data=02%7C01%7Cdleblanc%40exchange.microsoft.com%7C8094489204694756b65208d6bc87a1ff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636903688061734930&sdata=PowVVe%2FjRODqM2JC94pycbNZQRlOZmwnY2p4HiuUOkQ%3D&reserved=0>.
|
This includes the following fixes: nlohmann/json#1436 > For a deeply-nested JSON object, the recursive implementation of json_value::destroy function causes stack overflow. nlohmann/json#1708 nlohmann/json#1722 Stack size nlohmann/json#1693 (comment) Integer Overflow nlohmann/json#1447 UTF8, json dump out of bounds nlohmann/json#1445 Possibly influences #7532
This includes the following fixes: nlohmann/json#1436 > For a deeply-nested JSON object, the recursive implementation of json_value::destroy function causes stack overflow. nlohmann/json#1708 nlohmann/json#1722 Stack size nlohmann/json#1693 (comment) Integer Overflow nlohmann/json#1447 UTF8, json dump out of bounds nlohmann/json#1445 Possibly influences #7532
This includes the following fixes: nlohmann/json#1436 > For a deeply-nested JSON object, the recursive implementation of json_value::destroy function causes stack overflow. nlohmann/json#1708 nlohmann/json#1722 Stack size nlohmann/json#1693 (comment) Integer Overflow nlohmann/json#1447 UTF8, json dump out of bounds nlohmann/json#1445 Possibly influences #7532
Details:
Test case:
Note:
This may be related to #1411.
The text was updated successfully, but these errors were encountered: