Re: Patch for a overwriting/corruption of the file system

Re: Patch for a overwriting/corruption of the file system

[Greg KH]

On Mon, Mar 13, 2023 at 03:25:45PM +0530, Kirtikumar Anandrao Ramchandani wrote:
> Hello,
> 
> I am sending this patch which addresses a bug in the fs/affs/.

Your attachment was from a public patch on the f2fs mailing list, not
affs, are you sure you attached the correct one?

And the public mailing lists reject HTML email, please fix up your email
client to be able to send properly.

thanks,

greg k-h

Re: Patch for a overwriting/corruption of the file system

[Greg KH]

On Mon, Mar 13, 2023 at 03:54:55PM +0530, Kirtikumar Anandrao Ramchandani wrote:
> Seems like again it got rejected. I am sending it in the body if it works:
> 
> >From 839cae91705e044b49397590f2d85a5dd289f0c5 Mon Sep 17 00:00:00 2001
> From: KirtiRamchandani <kirtar15502@gmail.com>
> Date: Mon, 13 Mar 2023 15:05:08 +0530
> Subject: [PATCH] Fix bug in affs_rename() function. The `affs_rename()`
>  function in the AFFS filesystem has a bug that can cause the `retval`
>  variable to be overwritten before it is used. Specifically, the function
>  assigns `retval` a value in two separate code blocks, but then only checks
>  its value in one of those blocks. This commit fixes the bug by ensuring
> that
>  `retval` is properly checked in both code blocks.
> 
> Signed-off-by: KirtiRamchandani <kirtar15502@gmail.com>
> ---
>  namei.c | 4++++--
>  1 file changed, 4 insertions(+), 2 deletion(-)
> 
> diff --git a/fs/affs/namei.c b/fs/affs/namei.c
> index d1084e5..a54c700 100644
> --- a/fs/affs/namei.c
> +++ b/fs/affs/namei.c
> @@ -488,7 +488,8 @@ affs_xrename(struct inode *old_dir, struct dentry
> *old_dentry,
>         affs_lock_dir(new_dir);
>         retval = affs_insert_hash(new_dir, bh_old);
>         affs_unlock_dir(new_dir);
> -
> +       if (retval)
> +               goto done;

The patch is corrupted and can not be applied.

Here's the response from my patch bot.  Please read over the
documentation and try to submit it properly like any other normal
change.

------------


Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- Your patch is malformed (tabs converted to spaces, linewrapped, etc.)
  and can not be applied.  Please read the file,
  Documentation/process/email-clients.rst in order to fix this.

- You did not specify a description of why the patch is needed, or
  possibly, any description at all, in the email body.  Please read the
  section entitled "The canonical patch format" in the kernel file,
  Documentation/process/submitting-patches.rst for what is needed in
  order to properly describe the change.

- You did not write a descriptive Subject: for the patch, allowing Greg,
  and everyone else, to know what this patch is all about.  Please read
  the section entitled "The canonical patch format" in the kernel file,
  Documentation/process/submitting-patches.rst for what a proper
  Subject: line should look like.

- It looks like you did not use your "real" name for the patch on either
  the Signed-off-by: line, or the From: line (both of which have to
  match).  Please read the kernel file,
  Documentation/process/submitting-patches.rst for how to do this
  correctly.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot

Re: Patch for a overwriting/corruption of the file system

[Christian Brauner]

On Mon, Mar 13, 2023 at 11:32:08AM +0100, Greg KH wrote:
> On Mon, Mar 13, 2023 at 03:54:55PM +0530, Kirtikumar Anandrao Ramchandani wrote:
> > Seems like again it got rejected. I am sending it in the body if it works:
> > 
> > >From 839cae91705e044b49397590f2d85a5dd289f0c5 Mon Sep 17 00:00:00 2001
> > From: KirtiRamchandani <kirtar15502@gmail.com>
> > Date: Mon, 13 Mar 2023 15:05:08 +0530
> > Subject: [PATCH] Fix bug in affs_rename() function. The `affs_rename()`
> >  function in the AFFS filesystem has a bug that can cause the `retval`
> >  variable to be overwritten before it is used. Specifically, the function
> >  assigns `retval` a value in two separate code blocks, but then only checks
> >  its value in one of those blocks. This commit fixes the bug by ensuring
> > that
> >  `retval` is properly checked in both code blocks.
> > 
> > Signed-off-by: KirtiRamchandani <kirtar15502@gmail.com>
> > ---
> >  namei.c | 4++++--
> >  1 file changed, 4 insertions(+), 2 deletion(-)
> > 
> > diff --git a/fs/affs/namei.c b/fs/affs/namei.c
> > index d1084e5..a54c700 100644
> > --- a/fs/affs/namei.c
> > +++ b/fs/affs/namei.c
> > @@ -488,7 +488,8 @@ affs_xrename(struct inode *old_dir, struct dentry
> > *old_dentry,
> >         affs_lock_dir(new_dir);
> >         retval = affs_insert_hash(new_dir, bh_old);
> >         affs_unlock_dir(new_dir);
> > -
> > +       if (retval)
> > +               goto done;
> 
> The patch is corrupted and can not be applied.

Yeah, that patch is pretty borked. This should probably be sm like:

From f3a7758bb53cc776820656c6ac66b13fb8ed9022 Mon Sep 17 00:00:00 2001
From: KirtiRamchandani <kirtar15502@gmail.com>
Date: Tue, 14 Mar 2023 10:49:38 +0100
Subject: [PATCH] affs: handle errors in affs_xrename()

Fix a bug in the affs_xrename() function. The affs_xrename() function in
the AFFS filesystem has a bug that can cause the retval variable to be
overwritten before it is used. Specifically, the function assigns retval
a value in two separate code blocks, but then only checks its value in
one of those blocks. This commit fixes the bug by ensuring that retval
is properly checked in both code blocks.

Signed-off-by: KirtiRamchandani <kirtar15502@gmail.com>
---
 fs/affs/namei.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fs/affs/namei.c b/fs/affs/namei.c
index d12ccfd2a83d..98525d69391d 100644
--- a/fs/affs/namei.c
+++ b/fs/affs/namei.c
@@ -488,6 +488,8 @@ affs_xrename(struct inode *old_dir, struct dentry *old_dentry,
 	affs_lock_dir(new_dir);
 	retval = affs_insert_hash(new_dir, bh_old);
 	affs_unlock_dir(new_dir);
+	if (retval)
+		goto done;
 
 	/* Insert new into the old directory with the old name. */
 	affs_copy_name(AFFS_TAIL(sb, bh_new)->name, old_dentry);
@@ -495,6 +497,8 @@ affs_xrename(struct inode *old_dir, struct dentry *old_dentry,
 	affs_lock_dir(old_dir);
 	retval = affs_insert_hash(old_dir, bh_new);
 	affs_unlock_dir(old_dir);
+	if (retval)
+		goto done;
 done:
 	mark_buffer_dirty_inode(bh_old, new_dir);
 	mark_buffer_dirty_inode(bh_new, old_dir);
-- 
2.34.1

Re: Patch for a overwriting/corruption of the file system

[Al Viro]

On Tue, Mar 14, 2023 at 10:55:39AM +0100, Christian Brauner wrote:
> On Mon, Mar 13, 2023 at 11:32:08AM +0100, Greg KH wrote:
> > On Mon, Mar 13, 2023 at 03:54:55PM +0530, Kirtikumar Anandrao Ramchandani wrote:
> > > Seems like again it got rejected. I am sending it in the body if it works:
> > > 
> > > >From 839cae91705e044b49397590f2d85a5dd289f0c5 Mon Sep 17 00:00:00 2001
> > > From: KirtiRamchandani <kirtar15502@gmail.com>
> > > Date: Mon, 13 Mar 2023 15:05:08 +0530
> > > Subject: [PATCH] Fix bug in affs_rename() function. The `affs_rename()`
> > >  function in the AFFS filesystem has a bug that can cause the `retval`
> > >  variable to be overwritten before it is used. Specifically, the function
> > >  assigns `retval` a value in two separate code blocks, but then only checks
> > >  its value in one of those blocks. This commit fixes the bug by ensuring
> > > that
> > >  `retval` is properly checked in both code blocks.
> > > 
> > > Signed-off-by: KirtiRamchandani <kirtar15502@gmail.com>
> > > ---
> > >  namei.c | 4++++--
> > >  1 file changed, 4 insertions(+), 2 deletion(-)
> > > 
> > > diff --git a/fs/affs/namei.c b/fs/affs/namei.c
> > > index d1084e5..a54c700 100644
> > > --- a/fs/affs/namei.c
> > > +++ b/fs/affs/namei.c
> > > @@ -488,7 +488,8 @@ affs_xrename(struct inode *old_dir, struct dentry
> > > *old_dentry,
> > >         affs_lock_dir(new_dir);
> > >         retval = affs_insert_hash(new_dir, bh_old);
> > >         affs_unlock_dir(new_dir);
> > > -
> > > +       if (retval)
> > > +               goto done;
> > 
> > The patch is corrupted and can not be applied.
> 
> Yeah, that patch is pretty borked. This should probably be sm like:
> 
> >From f3a7758bb53cc776820656c6ac66b13fb8ed9022 Mon Sep 17 00:00:00 2001
> From: KirtiRamchandani <kirtar15502@gmail.com>
> Date: Tue, 14 Mar 2023 10:49:38 +0100
> Subject: [PATCH] affs: handle errors in affs_xrename()
> 
> Fix a bug in the affs_xrename() function. The affs_xrename() function in
> the AFFS filesystem has a bug that can cause the retval variable to be
> overwritten before it is used. Specifically, the function assigns retval
> a value in two separate code blocks, but then only checks its value in
> one of those blocks. This commit fixes the bug by ensuring that retval
> is properly checked in both code blocks.

"Properly checked" as in...?

> Signed-off-by: KirtiRamchandani <kirtar15502@gmail.com>
> ---
>  fs/affs/namei.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/fs/affs/namei.c b/fs/affs/namei.c
> index d12ccfd2a83d..98525d69391d 100644
> --- a/fs/affs/namei.c
> +++ b/fs/affs/namei.c
> @@ -488,6 +488,8 @@ affs_xrename(struct inode *old_dir, struct dentry *old_dentry,
>  	affs_lock_dir(new_dir);
>  	retval = affs_insert_hash(new_dir, bh_old);
>  	affs_unlock_dir(new_dir);
> +	if (retval)
> +		goto done;

OK, so you've got an IO error and insertion has failed.  Both entries had already
been removed from their directories.  Sure, we must report an error, but why is
leaking *both* entries the right thing to do?

>  	/* Insert new into the old directory with the old name. */
>  	affs_copy_name(AFFS_TAIL(sb, bh_new)->name, old_dentry);
> @@ -495,6 +497,8 @@ affs_xrename(struct inode *old_dir, struct dentry *old_dentry,
>  	affs_lock_dir(old_dir);
>  	retval = affs_insert_hash(old_dir, bh_new);
>  	affs_unlock_dir(old_dir);
> +	if (retval)
> +		goto done;
>  done:

Really?  How could that possibly make any sense?  I mean, look for the target of
that goto...

The bug here (AFFS awful layout aside) is that error from the first insert_hash
is always lost.  And it needs to be reported.  But this is no way to fix that.

Re: Patch for a overwriting/corruption of the file system

[Christian Brauner]

On Tue, Mar 14, 2023 at 04:57:08PM +0000, Al Viro wrote:
> On Tue, Mar 14, 2023 at 10:55:39AM +0100, Christian Brauner wrote:
> > On Mon, Mar 13, 2023 at 11:32:08AM +0100, Greg KH wrote:
> > > On Mon, Mar 13, 2023 at 03:54:55PM +0530, Kirtikumar Anandrao Ramchandani wrote:
> > > > Seems like again it got rejected. I am sending it in the body if it works:
> > > > 
> > > > >From 839cae91705e044b49397590f2d85a5dd289f0c5 Mon Sep 17 00:00:00 2001
> > > > From: KirtiRamchandani <kirtar15502@gmail.com>
> > > > Date: Mon, 13 Mar 2023 15:05:08 +0530
> > > > Subject: [PATCH] Fix bug in affs_rename() function. The `affs_rename()`
> > > >  function in the AFFS filesystem has a bug that can cause the `retval`
> > > >  variable to be overwritten before it is used. Specifically, the function
> > > >  assigns `retval` a value in two separate code blocks, but then only checks
> > > >  its value in one of those blocks. This commit fixes the bug by ensuring
> > > > that
> > > >  `retval` is properly checked in both code blocks.
> > > > 
> > > > Signed-off-by: KirtiRamchandani <kirtar15502@gmail.com>
> > > > ---
> > > >  namei.c | 4++++--
> > > >  1 file changed, 4 insertions(+), 2 deletion(-)
> > > > 
> > > > diff --git a/fs/affs/namei.c b/fs/affs/namei.c
> > > > index d1084e5..a54c700 100644
> > > > --- a/fs/affs/namei.c
> > > > +++ b/fs/affs/namei.c
> > > > @@ -488,7 +488,8 @@ affs_xrename(struct inode *old_dir, struct dentry
> > > > *old_dentry,
> > > >         affs_lock_dir(new_dir);
> > > >         retval = affs_insert_hash(new_dir, bh_old);
> > > >         affs_unlock_dir(new_dir);
> > > > -
> > > > +       if (retval)
> > > > +               goto done;
> > > 
> > > The patch is corrupted and can not be applied.
> > 
> > Yeah, that patch is pretty borked. This should probably be sm like:
> > 
> > >From f3a7758bb53cc776820656c6ac66b13fb8ed9022 Mon Sep 17 00:00:00 2001
> > From: KirtiRamchandani <kirtar15502@gmail.com>
> > Date: Tue, 14 Mar 2023 10:49:38 +0100
> > Subject: [PATCH] affs: handle errors in affs_xrename()
> > 
> > Fix a bug in the affs_xrename() function. The affs_xrename() function in
> > the AFFS filesystem has a bug that can cause the retval variable to be
> > overwritten before it is used. Specifically, the function assigns retval
> > a value in two separate code blocks, but then only checks its value in
> > one of those blocks. This commit fixes the bug by ensuring that retval
> > is properly checked in both code blocks.
> 
> "Properly checked" as in...?
> 
> > Signed-off-by: KirtiRamchandani <kirtar15502@gmail.com>
> > ---
> >  fs/affs/namei.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/fs/affs/namei.c b/fs/affs/namei.c
> > index d12ccfd2a83d..98525d69391d 100644
> > --- a/fs/affs/namei.c
> > +++ b/fs/affs/namei.c
> > @@ -488,6 +488,8 @@ affs_xrename(struct inode *old_dir, struct dentry *old_dentry,
> >  	affs_lock_dir(new_dir);
> >  	retval = affs_insert_hash(new_dir, bh_old);
> >  	affs_unlock_dir(new_dir);
> > +	if (retval)
> > +		goto done;
> 
> OK, so you've got an IO error and insertion has failed.  Both entries had already
> been removed from their directories.  Sure, we must report an error, but why is
> leaking *both* entries the right thing to do?
> 
> >  	/* Insert new into the old directory with the old name. */
> >  	affs_copy_name(AFFS_TAIL(sb, bh_new)->name, old_dentry);
> > @@ -495,6 +497,8 @@ affs_xrename(struct inode *old_dir, struct dentry *old_dentry,
> >  	affs_lock_dir(old_dir);
> >  	retval = affs_insert_hash(old_dir, bh_new);
> >  	affs_unlock_dir(old_dir);
> > +	if (retval)
> > +		goto done;
> >  done:
> 
> Really?  How could that possibly make any sense?  I mean, look for the target of
> that goto...
> 
> The bug here (AFFS awful layout aside) is that error from the first insert_hash
> is always lost.  And it needs to be reported.  But this is no way to fix that.

Note that I formatted that thing into something we can look at on the
list from the borked attachment; not acked it...

Re: Patch for a overwriting/corruption of the file system

[Al Viro]

On Wed, Mar 15, 2023 at 02:33:48PM +0530, Kirtikumar Anandrao Ramchandani wrote:
> While I am going through the code at the moment, I think there is one more
> issue. It probably can't just compare "old_dir" and "new_dir", since those
> are just pointers to structs. So, both addresses can be completely
> different, and still represent the same folder, yes?

No, they can not.  We should never have different in-core instances of
struct inode representing the same on-disk object - otherwise all locking
goes to hell, for example.

Re: Patch for a overwriting/corruption of the file system

[Al Viro]

On Fri, Apr 21, 2023 at 04:00:17AM +0100, Al Viro wrote:
> On Wed, Mar 15, 2023 at 02:33:48PM +0530, Kirtikumar Anandrao Ramchandani wrote:
> > While I am going through the code at the moment, I think there is one more
> > issue. It probably can't just compare "old_dir" and "new_dir", since those
> > are just pointers to structs. So, both addresses can be completely
> > different, and still represent the same folder, yes?
> 
> No, they can not.  We should never have different in-core instances of
> struct inode representing the same on-disk object - otherwise all locking
> goes to hell, for example.

... and we should never, ever have two dentries aliasing the same directory
inode, so d_inode() part is also not needed and actively confusing,
since anyone running into it is likely to go "Why is it written that way?
What is it protecting against?  Where does <such and such code> protect
itself against the same situation?".  And there's a _lot_ of code that
would break horribly if we ever run into such.

Defensive programming can be harmful...