On-stack initialization does not guarantee zeroying of unintialized
fields. So is.iloc.bh and bs.bh can be contain garbage of old stack
conent.
Errors in the beginning of ext4_xattr_set_handle() function
lead to jump to "cleanup:" label where brelse(is.iloc.bh)
and brelse(bs.bh) can access uninitialized bh fields of
on-stack located "is" and "bs" structures.
Issue was inherited from ext3 and was present in first ext4 commit.
Fixes ac27a0ec112a ("ext4: initial copy of files from ext3") # 2.6.19
Signed-off-by: Vasily Averin <[email protected]>
---
fs/ext4/xattr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index dc1aeab06dba..aae12425597e 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -2303,9 +2303,11 @@ ext4_xattr_set_handle(handle_t *handle, struct inode *inode, int name_index,
};
struct ext4_xattr_ibody_find is = {
.s = { .not_found = -ENODATA, },
+ .iloc = { .bh = NULL, },
};
struct ext4_xattr_block_find bs = {
.s = { .not_found = -ENODATA, },
+ .bh = NULL,
};
int no_expand;
int error;
--
2.17.1
On 10/31/2018 04:30 AM, Andreas Dilger wrote:
> Could you please explain your statement below that on-stack
> initialization does not zero unspecified fields? According
> to documents I found, for example:
>
> https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html
>
> they *are* initialized to zero.
I did not know it,
I re-checked it in generated assembler code and found that you are right and I was wrong.
Please drop this patch,
should I resend of rest of this patch set once again?
Thank you,
Vasily Averin
On Oct 30, 2018, at 9:39 PM, Vasily Averin <[email protected]> wrote:
>
> On 10/31/2018 04:30 AM, Andreas Dilger wrote:
>> Could you please explain your statement below that on-stack
>> initialization does not zero unspecified fields? According
>> to documents I found, for example:
>>
>> https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html
>>
>> they *are* initialized to zero.
>
> I did not know it,
> I re-checked it in generated assembler code and found that you
> are right and I was wrong.
>
> Please drop this patch,
> should I resend of rest of this patch set once again?
I don't think it is necessary to resend the whole patch series.
Ted should notice these emails on this patch and not apply it.
Cheers, Andreas