netdev - Re: rhashtable issue

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 for Android: free password hash cracker in your pocket

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

Message-ID: <4mnlqfprxh5zuvhjxqrqvqr2btaqggcuy5ofgvdlsxpwi3gljt@rd3pfavturcx>
Date: Tue, 26 Nov 2024 15:28:56 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: NeilBrown <neilb@...e.de>, Thomas Graf <tgraf@...g.ch>, 
	netdev@...r.kernel.org
Subject: Re: rhashtable issue - -EBUSY

On Tue, Nov 26, 2024 at 12:36:54PM +0800, Herbert Xu wrote:
> On Mon, Nov 25, 2024 at 11:35:48PM -0500, Kent Overstreet wrote:
> >
> > That knob was. That's not what I'm suggesting. Can you go back and
> > re-read my, and Neal's, suggestion?
> 
> That's exactly what the knob used to do.  Let you add entries
> without any limit.

No, the other option would be to add a knob to block until the rehash is
finished instead of returning -EBUSY - that wouldn't be insecure.

If allocating a bigger table is failing, that would require the limit on
chain length to increase in order to guarantee that inserts won't fail,
but that wouldn't be a security issue.