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
| ||
|
Date: Tue, 18 Feb 2020 13:40:26 -0800 From: Cong Wang <xiyou.wangcong@...il.com> To: Pablo Neira Ayuso <pablo@...filter.org> Cc: Linux Kernel Network Developers <netdev@...r.kernel.org>, Florian Westphal <fw@...len.de>, NetFilter <netfilter-devel@...r.kernel.org>, syzbot <syzbot+d195fd3b9a364ddd6731@...kaller.appspotmail.com> Subject: Re: [Patch nf] netfilter: xt_hashlimit: unregister proc file before releasing mutex On Tue, Feb 18, 2020 at 1:35 PM Pablo Neira Ayuso <pablo@...filter.org> wrote: > > On Wed, Feb 12, 2020 at 10:53:52PM -0800, Cong Wang wrote: > > Before releasing the global mutex, we only unlink the hashtable > > from the hash list, its proc file is still not unregistered at > > this point. So syzbot could trigger a race condition where a > > parallel htable_create() could register the same file immediately > > after the mutex is released. > > > > Move htable_remove_proc_entry() back to mutex protection to > > fix this. And, fold htable_destroy() into htable_put() to make > > the code slightly easier to understand. > > Probably revert previous one? The hung task could appear again if we move the cleanup back under mutex.
Powered by blists - more mailing lists