linux-kernel - Re: [PATCH 4/9] auditsc: test below 0 on unsigned ino

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20080722021324.GI28946@ZenIV.linux.org.uk>
Date:	Tue, 22 Jul 2008 03:13:24 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	roel kluin <roel.kluin@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/9] auditsc: test below 0 on unsigned ino

On Mon, Jul 21, 2008 at 08:29:16PM -0400, roel kluin wrote:
> ino is unsigned so the test didn't work.
                              ^^^^^^^^^^^

Kindly report the way to reproduce your remarkable observation.  Do not
forget to include the compiler version, since the following two lines

> -	if (ctx->names[index].ino == -1)
> +	if (ctx->names[index].ino == -1ul)

are equivalent.  -1 is an expression of type int.  ctx->names[index].ino
is an expression of type unsigned long.  If both operands of a comparison
operator have arithmetic types, the usual arithmetic conversions (see 6.3.1.8)
are applied to the operands.  In this case, both types are integer ones and
not modified by integer promotions.  One is signed, another is unsigned and
the rank of unsigned one is greater or equal to that of the signed one
(rank(unsigned long) = rank(signed long) > rank(signed int)).  Therefore,
the operand with signed integer type (-1) is converted to the type of
argument with unsigned integer type.  Then they are compared.

In the second case both operands have the same integer type (unsigned long)
and comparison is done without any conversions.

Proof that (unsigned long)-1 and -1ul have the same value (namely, the maximal
value that can be represented in unsigned long) is left as an exercise for
reader.

Assuming that you have indeed observed a case when results of these tests
differed, you have found a blatant non-compliance of whatever C compiler
you were using.  I am sure that maintainers of that compiler would like to
see your bug report, especially since you already have a reproducer.  So
would everybody else, to know which version to avoid.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/