netdev - Re: [PATCH net-next] net: socket: integrate sockfd_lookup() and sockfd_lookup

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]

Message-ID: <YU0+QDerqF5+pPB7@zeniv-ca.linux.org.uk>
Date:   Fri, 24 Sep 2021 02:56:00 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Yajun Deng <yajun.deng@...ux.dev>
Cc:     davem@...emloft.net, kuba@...nel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] net: socket: integrate sockfd_lookup() and
 sockfd_lookup_light()

On Wed, Sep 22, 2021 at 02:31:06PM +0800, Yajun Deng wrote:

> -#define		     sockfd_put(sock) fput(sock->file)
>  int net_ratelimit(void);
> +#define		     sockfd_put(sock)             \
> +do {                                              \
> +	struct fd *fd = (struct fd *)&sock->file; \

Have you even bothered to take a look at struct fd declaration?
Or struct socket one, for that matter...  What we have there is
	...
        struct file             *file;
	struct sock             *sk;
	...

You are taking the address of 'file' field.  And treat it as
a pointer to a structure consisting of struct file * and
unsigned int.

> +						  \
> +	if (fd->flags & FDPUT_FPUT)               \

... so that would take first 4 bytes in the memory occupied
by 'sk' field of struct socket and check if bit 0 is set.

And what significance would that bit have, pray tell?  On
little-endian architectures it's going to be the least
significant bit in the first byte in 'sk' field.  I.e.
there you are testing if the contents of 'sk' (a pointer
to struct sock) happens to be odd.  It won't be.  The
same goes for 32bit big-endian - there you will be checking
the least significant bit of the 4th byte of 'sk', which
again is asking 'is the pointer stored there odd for some
reason?'

On 64bit big-endian you are checking if the bit 32 of
the address of object sock->sk points to is set.  And the
answer to that is "hell knows and how could that possibly
be relevant to anything?"