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: Tue, 19 Oct 2021 09:02:54 +0300 From: Amir Goldstein <amir73il@...il.com> To: Gabriel Krisman Bertazi <krisman@...labora.com> Cc: Jan Kara <jack@...e.com>, "Darrick J. Wong" <djwong@...nel.org>, Theodore Tso <tytso@....edu>, Dave Chinner <david@...morbit.com>, David Howells <dhowells@...hat.com>, Khazhismel Kumykov <khazhy@...gle.com>, linux-fsdevel <linux-fsdevel@...r.kernel.org>, Ext4 <linux-ext4@...r.kernel.org>, Linux API <linux-api@...r.kernel.org>, kernel@...labora.com Subject: Re: [PATCH v8 26/32] fanotify: WARN_ON against too large file handles On Tue, Oct 19, 2021 at 3:03 AM Gabriel Krisman Bertazi <krisman@...labora.com> wrote: > > struct fanotify_error_event, at least, is preallocated and isn't able to > to handle arbitrarily large file handles. Future-proof the code by > complaining loudly if a handle larger than MAX_HANDLE_SZ is ever found. > > Signed-off-by: Gabriel Krisman Bertazi <krisman@...labora.com> Reviewed-by: Amir Goldstein <amir73il@...il.com> > --- > fs/notify/fanotify/fanotify.c | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c > index cedcb1546804..45df610debbe 100644 > --- a/fs/notify/fanotify/fanotify.c > +++ b/fs/notify/fanotify/fanotify.c > @@ -360,13 +360,23 @@ static u32 fanotify_group_event_mask(struct fsnotify_group *group, > static int fanotify_encode_fh_len(struct inode *inode) > { > int dwords = 0; > + int fh_len; > > if (!inode) > return 0; > > exportfs_encode_inode_fh(inode, NULL, &dwords, NULL); > + fh_len = dwords << 2; > > - return dwords << 2; > + /* > + * struct fanotify_error_event might be preallocated and is > + * limited to MAX_HANDLE_SZ. This should never happen, but > + * safeguard by forcing an invalid file handle. > + */ > + if (WARN_ON_ONCE(fh_len > MAX_HANDLE_SZ)) > + return 0; > + > + return fh_len; > } > > /* > -- > 2.33.0 >
Powered by blists - more mailing lists