-
Notifications
You must be signed in to change notification settings - Fork 707
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
Incorrect size for long double when using old rust_target #1529
Comments
Related issue: #317 I did some digging, and now I see a host of other, also potentially severe, issues that have been IMHO mishandled: #465 #743 #867 #1194. All these issues silently output incorrect code. Considering that |
That is just not true. Bindgen outputs layout tests that detect these issues. In the case of a single long double used as an argument to the function we don't emit anything. The rest of the issues mentioned there do cause failing unit tests in the final crate. |
Sorry you might be right about the unit tests, that's my mistake. Still this issue is not fixed and really needs to be addressed, this one does not trigger any test failure for me! Running void mul_assign_long_double(long double *input, double multiplier); Gives this output (which passes unit tests): /* automatically generated by rust-bindgen */
extern "C" { # [ link_name = "\u{1}_mul_assign_long_double" ] pub fn mul_assign_long_double ( input : * mut f64 , multiplier : f64 ) ; } The |
Yes, I understand the issue, but to be clear, for context:
I personally disagree. If that was the procedure, all compiler versions that ever miscompiled something should be yanked. Rust (and clang, and gcc, and every other compiler, for that matter) has miscompilation bugs. As I said in the other issue, I agree its maybe a bit unfortunate that the default configuration is
Please read the other issue. This is fixed if you pass a |
Ok I see that it has been fixed when you pass a higher |
And there is no indication anywhere that you need to do anything other than use |
That has the wrong alignment. Anyhow, #1530. |
Ok that should fix it for most people, but still it's important that 1. despite the rust target, the proper code (or an error message) is produced, and 2. people are aware of this issue in more than just release notes (I'm not sure what the best way to do this is, but just to make sure that people who are currently using old versions of |
I apologize if I made too big a deal of this. The main reason for my concern is that this issue slips through unit tests and before just now, it was the default behavior for both command-line and build script usage. |
No worries. I'll just note that I maintain bindgen on my free time (I don't get paid at all to do this), and that overly aggressive comments is not the most pleasant thing to deal with on a Sunday evening. Anyhow, I appreciate the report, this was overdue in any case. |
I'm sorry if I came off as aggressive, and I realize that I should not have unrealistic expectations for a community-maintained project, I'm not paid either after all 😂 |
Long story short,
long double
s are mistreated, leading to a SEVERE security/stability issue. I don't think I am overreacting. On some platforms (for example, my own computer),long double
s are 16 bytes! Not 8! This can cause a stack/heap overflow and all sorts of issues. This is enough to trigger the bug!:foo.h
:foo.c
:test.rs
:Output:
Notice that
b
has been affected! (the middle value of the array). It changed from16391
to16417
. This is because although we only pass a pointer toa
, it is interpreted as a 16-byte pointer, buta
only has enough space for 8 bytes so it overwrites into 2 bytes ofb
! Sorry for all the exclamation points, but this is a serious issue!This is a very very bad thing.
In addition to fixing this issue, this must be treated as a severe vulnerability. Personally I would:
rust-bindgen
with mission-critical code should stop anything built withrust-bindgen
until they get a fixed version and update their codeIt would be very easy to import a large C header/library, see a
f64
where it would make sense, and assume everything is OK. And all tests might pass. But then when you run your code in production, the stack is corrupted! Not only could this happen randomly with well-behaved code, but it could also be exploited to overwrite up to 2 bytes (long double
is usually only 10 important bytes; 10 - 8 = 2) on the stack with attacker-controlled values. Plus it would be very hard to debug. That is why I am treating this so seriously! In issues like #1338 and #550, it has been brushed off and treated as a small bug because there is no easy fix, but currently, it is not just a bug, it is actually unsafe/undefined behavior, and AFAIK there is no warning about it at all.Since Rust does not have a
f128
, there is no clear replacement, but that debate can be held later (u128
?[u64; 2]
?). Right now, I think the main concern should be at the very least notifying people usingrust-bindgen
about this issue.The text was updated successfully, but these errors were encountered: