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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 09 Oct 2020 07:38:59 +0200 From: Nicolai Stange <nstange@...e.de> To: Taehee Yoo <ap420073@...il.com> Cc: Johannes Berg <johannes@...solutions.net>, David Laight <David.Laight@...lab.com>, "davem\@davemloft.net" <davem@...emloft.net>, "kuba\@kernel.org" <kuba@...nel.org>, "netdev\@vger.kernel.org" <netdev@...r.kernel.org>, Nicolai Stange <nstange@...e.de>, "linux-wireless\@vger.kernel.org" <linux-wireless@...r.kernel.org>, "wil6210\@qti.qualcomm.com" <wil6210@....qualcomm.com>, "brcm80211-dev-list\@cypress.com" <brcm80211-dev-list@...ress.com>, "b43-dev\@lists.infradead.org" <b43-dev@...ts.infradead.org>, "linux-bluetooth\@vger.kernel.org" <linux-bluetooth@...r.kernel.org> Subject: Re: [PATCH net 000/117] net: avoid to remove module when its debugfs is being used Taehee Yoo <ap420073@...il.com> writes: > On Fri, 9 Oct 2020 at 01:14, Johannes Berg <johannes@...solutions.net> wrote: > On Thu, 2020-10-08 at 15:59 +0000, David Laight wrote: > >> From: Taehee Yoo >> > Sent: 08 October 2020 16:49 >> > >> > When debugfs file is opened, its module should not be removed until >> > it's closed. >> > Because debugfs internally uses the module's data. >> > So, it could access freed memory. Yes, the file_operations' ->release() to be more specific -- that's not covered by debugfs' proxy fops. >> > In order to avoid panic, it just sets .owner to THIS_MODULE. >> > So that all modules will be held when its debugfs file is opened. >> >> Can't you fix it in common code? > >> Yeah I was just wondering that too - weren't the proxy_fops even already >> intended to fix this? > > I didn't try to fix this issue in the common code(debugfs). > Because I thought It's a typical pattern of panic and THIS_MODULE > can fix it clearly. > So I couldn't think there is a root reason in the common code. That's correct, ->owner should get set properly, c.f. my other mail in this thread. Thanks, Nicolai -- SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg), GF: Felix Imendörffer
Powered by blists - more mailing lists