linux-kernel - Re: [PATCH] udf: shut up pointer cast warning

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 10 Nov 2021 12:00:38 +0100
From:   Jan Kara <jack@...e.cz>
To:     Arnd Bergmann <arnd@...nel.org>
Cc:     Jan Kara <jack@...e.com>, Arnd Bergmann <arnd@...db.de>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] udf: shut up pointer cast warning

On Tue 09-11-21 13:36:08, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@...db.de>
> 
> On 32-bit architectures, the workaround of storing the directory position
> in the private_data pointer causes a warning, as loff_t does not fit in
> a pointer:
> 
> fs/udf/dir.c: In function 'udf_readdir':
> fs/udf/dir.c:78:25: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
>    78 |         if (ctx->pos != (uintptr_t)file->private_data) {
>       |                         ^
> fs/udf/dir.c:211:30: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
>   211 |         file->private_data = (void *)(uintptr_t)ctx->pos;
>       |                              ^
> 
> An extra cast to uintptr_t shuts up the warning. This is of course
> still broken if the position is ever beyond the first 2^32 bytes (4GB).
> 
> I have not found a clear information on whether directories this
> large are allowed on UDF, but it seems unlikely.
> 
> Fixes: 39a464de961f ("udf: Fix crash after seekdir")
> Signed-off-by: Arnd Bergmann <arnd@...db.de>

Thanks Arnd but the problem was actually (mostly theoretical) problem on
32-bita archs and furthermore I've realized it didn't completely fix the
original problem either. Yesterday I've pushed a different fix to
linux-next. So the warning should disappear.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR