News for hackers. Stuff that matters.
Re:size_t-to-int vulnerability in Linux’s filesystem layer by gruez on Tuesday July 20, 2021 @11:05AM (#27894642)
AFAIK most compilers by default will output a warning in this case.
Re:size_t-to-int vulnerability in Linux’s filesystem layer by im3w1l on Tuesday July 20, 2021 @11:45AM (#27895165)
Too bad that most projects are so full of integer size and signedness warnings that people get warning fatigue and just completely ignore them.
Re:size_t-to-int vulnerability in Linux’s filesystem layer by usefulcat on Tuesday July 20, 2021 @04:12PM (#27898658)
GCC's -Wconversion has some issues. For example, good luck getting gcc to /not/ emit a warning for this code, in C or C++. I have yet to find the appropriate cast to avoid a warning. Clang does not warn for this.

    typedef struct {
        unsigned value : 4;
    } S;

    void foo(S* s, unsigned value) {
        // error: conversion from 'unsigned int' to 'unsigned char:4' may change value
        s->value = value;
    }
I mean, I guess I can see the rationale.. it's just annoying to have to resort to using pragmas to turn off -Wconversion whenever I need to assign to a bitfield.
Re:size_t-to-int vulnerability in Linux’s filesystem layer by Denvercoder9 on Tuesday July 20, 2021 @04:36PM (#27898949)
Does it still warn if you do `s->value = value & 0x0F`? That seems like a reasonable alternative to pragmas if it works.
Re:size_t-to-int vulnerability in Linux’s filesystem layer by usefulcat on Wednesday July 21, 2021 @09:10AM (#27905731)
Thanks, that fixed it!
Re:size_t-to-int vulnerability in Linux’s filesystem layer by owl57 on Tuesday July 20, 2021 @09:19PM (#27901218)
It doesn't.
Re:size_t-to-int vulnerability in Linux’s filesystem layer by loeg on Tuesday July 20, 2021 @12:56PM (#27896228)
GCC and Clang (the predominant Linux and Mac compilers) mostly don’t warn by default, you need -Wall or other flags (-Wextra, -Weverything, or specific flags like -Wconversion).
Re:size_t-to-int vulnerability in Linux’s filesystem layer by jeffbee on Tuesday July 20, 2021 @11:30AM (#27894959)
I don't see any warnings for this narrowing parameter conversion.

  #include "stddef.h"

  short foo(short a) { return a % 42; }
  
  size_t bar(void) {
      size_t sz = ~0UL;
      return foo(sz);
  }
https://godbolt.org/z/3ec9v8Pa4
Re:size_t-to-int vulnerability in Linux’s filesystem layer by gruez on Tuesday July 20, 2021 @12:04PM (#27895481)
On MSVC, default project settings I get:

    warning C4267: 'argument': conversion from 'size_t' to 'short', possible loss of data
https://godbolt.org/z/nYeWT7zv6 (/W3 is the default warning level when creating a new project)

I saw these warnings so often that I assumed that every compiler had them.

Re:size_t-to-int vulnerability in Linux’s filesystem layer by xeeeeeeeeeeenu on Tuesday July 20, 2021 @11:37AM (#27895049)
It warns if you add -Wconversion. Unfortunately, that flag generates lots of false positives (at least in gcc), so using it isn't always a good idea.
Re:size_t-to-int vulnerability in Linux’s filesystem layer by morio on Tuesday July 20, 2021 @12:18PM (#27895720)
What kind of false positives are you seeing with gcc?

Personally I have never seen gcc spitting out a false positive. IMO it's always a good idea to explicitly downcast even if you know that it's 'safe'. That way someone else will see instantly what's going on. The fact that Rust requires it should tell us something.

Re:size_t-to-int vulnerability in Linux’s filesystem layer by xeeeeeeeeeeenu on Tuesday July 20, 2021 @02:00PM (#27897025)
For example, I've just reported this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101537

You can find more cases in the bugtracker. To be fair, it seems many of them were fixed in recent releases.

Re:size_t-to-int vulnerability in Linux’s filesystem layer by Cloudef on Wednesday July 21, 2021 @12:38AM (#27902395)
The 1 and 0 are ints. It most likely complaints because the sign isn't same.
Re:size_t-to-int vulnerability in Linux’s filesystem layer by jeffbee on Tuesday July 20, 2021 @12:01PM (#27895409)
It isn't ever a good idea. C programmers are just supposed to know about the conversion and promotion rules, every time they add a line, even though the rules are actually insanely complicated. Compiler warnings can't overcome this because programmers have no way of just discovering one of GCC's 726 warning flags, only a few of which are enabled by -Wall and -Wextra, most of which are way too noisy to serve a useful purpose.
Re:size_t-to-int vulnerability in Linux’s filesystem layer by ototot on Tuesday July 20, 2021 @12:34PM (#27895944)
In my own small projects, I always add -Wconversion to build configuration. I think the false positive is affordable when you start from small piece of code.
Re:size_t-to-int vulnerability in Linux’s filesystem layer by saurik on Tuesday July 20, 2021 @11:38AM (#27895053)
Yeah; AFAIK you need something like clang-tidy's cppcoreguidelines-narrowing-conversions check (which everyone should definitely be using). (edit: But I'm wrong! That check is apparently similar to the -Wconversion mentioned by someone else.)
Re:size_t-to-int vulnerability in Linux’s filesystem layer by nly on Tuesday July 20, 2021 @01:18PM (#27896498)
They can't warn by default, because on some platforms long->int isnt a narrowing conversion.
Re:size_t-to-int vulnerability in Linux’s filesystem layer by aaronmdjones on Tuesday July 20, 2021 @01:40PM (#27896746)
The compiler knows what platform it's compiling the code for, though.