fix kernel crash on stable/linux-3.4.y

fix kernel crash on stable/linux-3.4.y

[Christian Groessler]

[-- Attachment #1: Type: text/plain, Size: 110 bytes --]

Hi,

the attached patch prevents a crash when trying to mount a corrupted 
ext4 file system.

regards,
chris


[-- Attachment #2: 0001-Fix-kernel-crash-when-trying-to-mount-corrupted-ext4.patch --]
[-- Type: text/x-patch, Size: 1150 bytes --]

>From 86344aebe7e3905b2293a7891a68def8cb38a571 Mon Sep 17 00:00:00 2001
From: Christian Groessler <chris@groessler.org>
Date: Wed, 7 Dec 2016 00:54:03 +0100
Subject: [PATCH] Fix kernel crash when trying to mount corrupted ext4
 partition.

ext4_calculate_overhead(), if successful, sets the 'ret' vatiable to 0.
Subsequent failures will bail out, with the function returning the 'ret'
variable as status. Since 'ret' is 0 (indicating no error) the kernel
will happily continue and eventually crash.

This change preserves the value of 'ret' across the call to
ext4_calculate_overhead() in case this function doesn't return an
error.

Signed-off-by: Christian Groessler <chris@groessler.org>
---
 fs/ext4/super.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 5862518..0f63644 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3692,9 +3692,12 @@ no_journal:
 	if (es->s_overhead_clusters)
 		sbi->s_overhead = le32_to_cpu(es->s_overhead_clusters);
 	else {
+		int oret = ret;
 		ret = ext4_calculate_overhead(sb);
 		if (ret)
 			goto failed_mount_wq;
+		else
+			ret = oret;
 	}
 
 	/*
-- 
2.7.4

Re: fix kernel crash on stable/linux-3.4.y

[Willy Tarreau]

Hi,

On Wed, Dec 07, 2016 at 01:22:00AM +0100, Christian Groessler wrote:
> Hi,
> 
> the attached patch prevents a crash when trying to mount a corrupted ext4
> file system.

Why isn't it a backport of the equivalent mainline commit ? Is mainline
not affected by the same bug ? Unless this is the case (and the mainline
commit which made this one unnecessary) all fixes must go to mainline
first before being backported to stable.

> regards,
> chris
> 

Thanks,
Willy

---
> >From 86344aebe7e3905b2293a7891a68def8cb38a571 Mon Sep 17 00:00:00 2001
> From: Christian Groessler <chris@groessler.org>
> Date: Wed, 7 Dec 2016 00:54:03 +0100
> Subject: [PATCH] Fix kernel crash when trying to mount corrupted ext4
>  partition.
> 
> ext4_calculate_overhead(), if successful, sets the 'ret' vatiable to 0.
> Subsequent failures will bail out, with the function returning the 'ret'
> variable as status. Since 'ret' is 0 (indicating no error) the kernel
> will happily continue and eventually crash.
> 
> This change preserves the value of 'ret' across the call to
> ext4_calculate_overhead() in case this function doesn't return an
> error.
> 
> Signed-off-by: Christian Groessler <chris@groessler.org>
> ---
>  fs/ext4/super.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index 5862518..0f63644 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -3692,9 +3692,12 @@ no_journal:
>  	if (es->s_overhead_clusters)
>  		sbi->s_overhead = le32_to_cpu(es->s_overhead_clusters);
>  	else {
> +		int oret = ret;
>  		ret = ext4_calculate_overhead(sb);
>  		if (ret)
>  			goto failed_mount_wq;
> +		else
> +			ret = oret;
>  	}
>  
>  	/*
> -- 
> 2.7.4
> 

Re: fix kernel crash on stable/linux-3.4.y

[Greg KH]

On Wed, Dec 07, 2016 at 01:22:00AM +0100, Christian Groessler wrote:
> Hi,
> 
> the attached patch prevents a crash when trying to mount a corrupted ext4
> file system.

<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
for how to do this properly.

</formletter>

Re: fix kernel crash on stable/linux-3.4.y

[Christian Groessler]

Hi,

On 12/07/16 07:30, Willy Tarreau wrote:
> On Wed, Dec 07, 2016 at 01:22:00AM +0100, Christian Groessler wrote:
>> Hi,
>>
>> the attached patch prevents a crash when trying to mount a corrupted ext4
>> file system.
> Why isn't it a backport of the equivalent mainline commit ?


Good question.


> Is mainline
> not affected by the same bug ?


The bug was fixed in mainline with commit 07aa2ea13814e.

I will backport that and resubmit.

regards,
chris