add lint deref_nullptr detecting when a null ptr is dereferenced #83948

ABouttefeux · 2021-04-06T20:19:46Z

fixes #83856
changelog: add lint that detect code like

unsafe {
      &*core::ptr::null::<i32>()
 };
unsafe {
     addr_of!(*std::ptr::null::<i32>())
};
let x: i32 = unsafe {*core::ptr::null()};
let x: i32 = unsafe {*core::ptr::null_mut()};
unsafe {*(0 as *const i32)};
unsafe {*(core::ptr::null() as *const i32)};

warning: Dereferencing a null pointer causes undefined behavior
 --> src\main.rs:5:26
  |
5 |     let x: i32 = unsafe {*core::ptr::null()};
  |                          ^^^^^^^^^^^^^^^^^^
  |                          |
  |                          a null pointer is dereferenced
  |                          this code causes undefined behavior when executed
  |
  = note: `#[warn(deref_nullptr)]` on by default

Limitation:
It does not detect code like

const ZERO: usize = 0;
unsafe {*(ZERO as *const i32)};

or code where 0 is not directly a literal

rust-highfive · 2021-04-06T20:19:49Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @lcnr (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

jyn514 · 2021-04-06T21:45:46Z

I thought the plan was to uplift the existing clippy lint?

jyn514 · 2021-04-06T21:46:17Z

r? @RalfJung

RalfJung · 2021-04-06T22:21:41Z

Thanks a lot. :)
It might take until the weekend that I have time to review this. However, one thing already: please add a test file in src/test/ui. See the docs for how to write a test.

The CI failure is caused by that file crossing the threshold of 3000 lines... I am not sure what to do about that though, so adding // ignore-tidy-filelength to the file seems okay to me. 🤷

RalfJung · 2021-04-06T22:22:57Z

I thought the plan was to uplift the existing clippy lint?

Yeah it is at least the easiest option I think... @ABouttefeux did you use the clippy lint as a basis or write this from scratch? It would be good to at least ensure that we catch all the same cases. Clippy will likely have tests that you can also use as inspiration.

ABouttefeux · 2021-04-07T06:40:08Z

I wrote it from scratch. I will look at the clippy lint.

ABouttefeux · 2021-04-07T08:16:26Z

Also from what I see the lint clippy::zero_ptr is different from what is described in #83856.
From clippy's documentation

What it does

Catch casts from 0 to some pointer type

Example
// Bad
let a = 0 as *const u32;

// Good
let a = std::ptr::null::<u32>();

RalfJung · 2021-04-07T10:59:48Z

@ABouttefeux good point, that lint is not what we are looking for. Thanks for checking. :)

RalfJung · 2021-04-07T11:01:03Z

changelog: add lint that detect code like

Would be good to also mention &*core::ptr::null() and addr_of!(core::ptr::null()) in your examples (and have them in the test), just to drive home the point that the lint fires even in place expression context.

compiler/rustc_lint/src/builtin.rs

src/test/ui/lint/lint-deref-nullptr.rs

compiler/rustc_lint/src/builtin.rs

RalfJung · 2021-04-10T12:27:20Z

Btw, does this also detect addr_of!((*ptr::null::<Struct>()).field)?

if not, that could be an interesting future extension of this lint. :) If yes, please add a test. :D

ABouttefeux · 2021-04-10T12:40:45Z

I think it should detect that. I will add a test

src/test/ui/lint/lint-deref-nullptr.rs

apiraino · 2021-04-14T10:35:36Z

@scottmcm which team the I-nominated is relevant to? Perhaps the T-compiler? (asking because in case, this issue can be mentioned tomorrow during the compiler team meeting). Specifically, what should be discussed? Whether this should be a clippy lint?

(thanks for the additional context)

RalfJung · 2021-04-14T11:09:05Z

I was told lints are lang team territory so setting the flag accordingly.

RalfJung · 2021-04-14T15:47:57Z

@scottmcm wrote on Zulip

Personally, I think it should just go in because it's not a one-way door -- we can always tweak it (behaviour, severity, or even remove it entirely) later if needed, so I don't see a strict need for an FCP. I'll motion that you can r+ it on my lang member "seems reasonable", the same way unstable library items can go in on a libs member "seems reasonable".

So, let's go with this then. :) @bors r+

bors · 2021-04-14T15:47:59Z

📌 Commit 7f0f83a has been approved by RalfJung

…alfJung add lint deref_nullptr detecting when a null ptr is dereferenced fixes rust-lang#83856 changelog: add lint that detect code like ```rust unsafe { &*core::ptr::null::<i32>() }; unsafe { addr_of!(std::ptr::null::<i32>()) }; let x: i32 = unsafe {*core::ptr::null()}; let x: i32 = unsafe {*core::ptr::null_mut()}; unsafe {*(0 as *const i32)}; unsafe {*(core::ptr::null() as *const i32)}; ``` ``` warning: Dereferencing a null pointer causes undefined behavior --> src\main.rs:5:26 | 5 | let x: i32 = unsafe {*core::ptr::null()}; | ^^^^^^^^^^^^^^^^^^ | | | a null pointer is dereferenced | this code causes undefined behavior when executed | = note: `#[warn(deref_nullptr)]` on by default ``` Limitation: It does not detect code like ```rust const ZERO: usize = 0; unsafe {*(ZERO as *const i32)}; ``` or code where `0` is not directly a literal

bors · 2021-04-14T18:04:27Z

⌛ Testing commit 7f0f83a with merge 7537b20...

bors · 2021-04-14T20:45:18Z

☀️ Test successful - checks-actions
Approved by: RalfJung
Pushing 7537b20 to master...

rust-highfive · 2021-04-14T20:45:59Z

📣 Toolstate changed by #83948!

Tested on commit 7537b20.
Direct link to PR: #83948

💔 miri on windows: test-pass → test-fail (cc @oli-obk @RalfJung @eddyb).
💔 miri on linux: test-pass → test-fail (cc @oli-obk @RalfJung @eddyb).

@oli-obk

Tested on commit rust-lang/rust@7537b20. Direct link to PR: <rust-lang/rust#83948> 💔 miri on windows: test-pass → test-fail (cc @oli-obk @RalfJung @eddyb). 💔 miri on linux: test-pass → test-fail (cc @oli-obk @RalfJung @eddyb).

WaffleLapkin · 2021-04-23T11:47:11Z

PR description is a bit missleading:

unsafe {
     addr_of!(std::ptr::null::<i32>())
};

Doesn't trigger the lint (there is no dereference), moreover this doesn't compile (cannot take address of a temporary).

What does trigger the lint is

unsafe {
     addr_of!(*std::ptr::null::<i32>())
     //       ^ deref
};

RalfJung · 2021-04-23T12:45:58Z

@WaffleLapkin thanks for pointing that out, I fixed the PR description.

…rochenkov Make deref_nullptr deny by default instead of warn This lint was added 4 years ago in rust-lang#83948 and I cannot find any discussion on that PR or its issue about whether it should be warn or deny by default. I think keeping this lint to warn was at one point in the past justifiable because of the old bindgen behavior of generating tests that do null pointer derefs. I've certainly heard that argument. I don't think it holds up now, so I think we should be more firm about code that is definitely UB. We merged rust-lang#134424 which adds a runtime check for null pointer reads/writes, with very little fanfare. So now we know things like: This lint warns on 111 crates in crater, but 106 crates are encountering the runtime UB check. 65 crates hit both the lint and a runtime check. Of the 46 crates that only hit the lint, 25 look to me like machine-generated bindings, and all hits except https://github.com/Plecra/asm-w-ownership/blob/3a0eff4bd151d8a0ccc076d6b8dea0bbc051e8e8/src/main.rs#L454 are trying to compute a field offset, and should use `offset_of!`. Based on the contents of the crater runs for 1.91, I'd expect these crates to go from test-fail to build-fail as a result of this change: ``` gh/bernardjason/rust-invaders gh/Leinnan/doppler gh/Max-E/rust-gl-python-gtk gh/nslebruh/rust-opengl-glfw gh/nslebruh/rust_physics_gl_test gh/oraoto/php-stacktrace gh/playXE/jsrs gh/Plecra/asm-w-ownership gh/TateKennington/ROpenGL gh/WillFarris/voxel-game reg/ochre ``` Most of the crates where the lint fires already don't build for other reasons (note there are a lot of C bindings wrapper crates in the set).

Make deref_nullptr deny by default instead of warn This lint was added 4 years ago in #83948 and I cannot find any discussion on that PR or its issue about whether it should be warn or deny by default. I think keeping this lint to warn was at one point in the past justifiable because of the old bindgen behavior of generating tests that do null pointer derefs. I've certainly heard that argument. I don't think it holds up now, so I think we should be more firm about code that is definitely UB. We merged #134424 which adds a runtime check for null pointer reads/writes, with very little fanfare. So now we know things like: This lint warns on 111 crates in crater, but 106 crates are encountering the runtime UB check. 65 crates hit both the lint and a runtime check. Of the 46 crates that only hit the lint, 25 look to me like machine-generated bindings, and all hits except https://github.com/Plecra/asm-w-ownership/blob/3a0eff4bd151d8a0ccc076d6b8dea0bbc051e8e8/src/main.rs#L454 are trying to compute a field offset, and should use `offset_of!`. Based on the contents of the crater runs for 1.91, I'd expect these crates to go from test-fail to build-fail as a result of this change: ``` gh/bernardjason/rust-invaders gh/Leinnan/doppler gh/Max-E/rust-gl-python-gtk gh/nslebruh/rust-opengl-glfw gh/nslebruh/rust_physics_gl_test gh/oraoto/php-stacktrace gh/playXE/jsrs gh/Plecra/asm-w-ownership gh/TateKennington/ROpenGL gh/WillFarris/voxel-game reg/ochre ``` Most of the crates where the lint fires already don't build for other reasons (note there are a lot of C bindings wrapper crates in the set).

add lint deref_nullptr

3891009

rust-highfive assigned lcnr Apr 6, 2021

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 6, 2021

ABouttefeux changed the title ~~add lint deref_nullptr detecting when a null ptr is dereference~~ add lint deref_nullptr detecting when a null ptr is dereferenced Apr 6, 2021

This comment has been minimized.

Sign in to view

rust-highfive assigned RalfJung and unassigned lcnr Apr 6, 2021

add test

c7bc41f

This comment has been minimized.

Sign in to view

ABouttefeux force-pushed the lint-nullprt-deref branch from fed2e52 to e1a1bbc Compare April 7, 2021 19:24

This comment has been minimized.

Sign in to view

change documentation of lint

3d215bd

ABouttefeux force-pushed the lint-nullprt-deref branch from e1a1bbc to 3d215bd Compare April 7, 2021 19:54

This comment has been minimized.

Sign in to view