Skip to content

llvm lint: buffer overflow in src/test/ui/foreign/foreign-truncated-arguments.rs #75839

Closed

Description

@matthiaskrgr

code from tests/ui/foreign/foreign-truncated-arguments.rs

// run-pass
// compile-flags: -O
// Regression test for https://github.com/rust-lang/rust/issues/33868

#[repr(C)]
pub struct S {
    a: u32,
    b: f32,
    c: u32
}

#[no_mangle]
#[inline(never)]
pub extern "C" fn test(s: S) -> u32 {
    s.c
}

fn main() {
    assert_eq!(test(S{a: 0, b: 0.0, c: 42}), 42);
}

When checked with rustc -Cpasses=lint src/test/ui/foreign/foreign-truncated-arguments.rs, this generates the following llvm-ir lint warning:

Undefined behavior: Buffer overflow
  %13 = load { i64, i32 }, { i64, i32 }* %12, align 4

repo @ 2342cc3

Activity

  1. cuviper commented on Aug 24, 2020

    @cuviper
    Member

    I captured the LLVM-IR in a single codegen unit, then ran opt -lint which has the same complaint, just on %4.

    $ opt -disable-output -lint foreign-truncated-arguments.ll
    Undefined behavior: Buffer overflow
      %4 = load { i64, i32 }, { i64, i32 }* %3, align 4
    

    Here are the relevant snippets from that IR:

    %S = type { [0 x i32], i32, [0 x i32], float, [0 x i32], i32, [0 x i32] }
    [...]
    ; foreign_truncated_arguments::main
    ; Function Attrs: nonlazybind uwtable
    define internal void @_ZN27foreign_truncated_arguments4main17h8a09fc9d120f0135E() unnamed_addr #1 {
    start:
      %_26 = alloca i32*, align 8
      %_24 = alloca i32*, align 8
      %_22 = alloca { i64*, i64* }, align 8
      %_21 = alloca [2 x { i8*, i64* }], align 8
      %_14 = alloca %"core::fmt::Arguments", align 8
      %_4 = alloca %S, align 4
      %_3 = alloca i32, align 4
      %_1 = alloca { i32*, i32* }, align 8
      %0 = bitcast %S* %_4 to i32*
      store i32 0, i32* %0, align 4
      %1 = getelementptr inbounds %S, %S* %_4, i32 0, i32 3
      store float 0.000000e+00, float* %1, align 4
      %2 = getelementptr inbounds %S, %S* %_4, i32 0, i32 5
      store i32 42, i32* %2, align 4
      %3 = bitcast %S* %_4 to { i64, i32 }*
      %4 = load { i64, i32 }, { i64, i32 }* %3, align 4
      %5 = call i32 @test({ i64, i32 } %4)
      store i32 %5, i32* %_3, align 4
      br label %bb1

    I expect S has size 12, but { i64, i32 } would have alignment padding up to size 16.

    The lint goes away if I change all { i64, i32 } to packed <{ i64, i32 }>, but maybe we can do better than that.

  2. added
    A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    and removed on Jan 31, 2024
  3. mmastrac commented on Apr 13, 2024

    @mmastrac

    We've been working on enabling ASAN in rusty_v8 (https://github.com/denoland/rusty_v8) and we suspect this is causing some real-world bugs when we call into V8 from Rust. In particular, some exceptions in V8 aren't correctly detected when we compile the Rust parts with opt-level=0.

  4. added
    A-codegenArea: Code generation
    I-unsoundIssue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness
    S-has-mcveStatus: A Minimal Complete and Verifiable Example has been found for this issue
    on Apr 13, 2024
  5. added
    I-prioritizeIssue needs a team member to assess the impact. Will be replaced by P-{low,medium,high,critical}
    on Apr 13, 2024
  6. apiraino commented on Apr 15, 2024

    @apiraino
    Contributor

    WG-prioritization assigning priority (Zulip discussion).

    @rustbot label -I-prioritize +P-high

  7. added
    P-highHigh priority
    and removed
    I-prioritizeIssue needs a team member to assess the impact. Will be replaced by P-{low,medium,high,critical}
    on Apr 15, 2024
  8. dianqk commented on Jun 30, 2024

    @dianqk
    Member

    { i64, i32 } should have 16 bytes on x86_64.

    @rustbot claim

  9. added a commit that references this issue on Jul 2, 2024
    7a59bfd
  10. added a commit that references this issue on Jul 2, 2024
    33b0238
  11. added a commit that references this issue on Jul 2, 2024
    34591e5
  12. apiraino commented on Jul 3, 2024

    @apiraino
    Contributor

    reopening to follow the beta backport of #127168

  13. dianqk commented on Jul 4, 2024

    @dianqk
    Member

    We've been working on enabling ASAN in rusty_v8 (https://github.com/denoland/rusty_v8) and we suspect this is causing some real-world bugs when we call into V8 from Rust. In particular, some exceptions in V8 aren't correctly detected when we compile the Rust parts with opt-level=0.

    @mmastrac Can you reproduce the problem on the latest nightly? I can't confirm that #127168 has fixed it.

  14. dianqk commented on Jul 5, 2024

    @dianqk
    Member

    @apiraino We can close it again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.A-codegenArea: Code generationC-bugCategory: This is a bug.I-unsoundIssue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/SoundnessP-highHigh priorityS-has-mcveStatus: A Minimal Complete and Verifiable Example has been found for this issueT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.WG-llvmWorking group: LLVM backend code generation

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions