On 11/21/2017 09:23 PM, Ladislav Michl wrote:
On Tue, Nov 21, 2017 at 07:45:03PM +0100, Heinrich Schuchardt wrote:
If 'file' cannot be allocated due to an out of memory
situation, do not dereference it.
When debugging this patch also avoids a misleading message
"cannot find next direntry, error %d" in case of an out of
memory situation. It is sufficent to write
"%s: Error, no memory for malloc!\n" in this case.
Reported-by: Alex Sadovsky <nable.mainin...@googlemail.com>
Signed-off-by: Heinrich Schuchardt <xypron.g...@gmx.de>
---
fs/ubifs/ubifs.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
index 4465523d5f..313dee0579 100644
--- a/fs/ubifs/ubifs.c
+++ b/fs/ubifs/ubifs.c
@@ -403,8 +403,7 @@ static int ubifs_finddir(struct super_block *sb, char
*dirname,
dir = kzalloc(sizeof(struct inode), 0);
if (!file || !dentry || !dir) {
printf("%s: Error, no memory for malloc!\n", __func__);
- err = -ENOMEM;
- goto out;
+ goto out_nomem;
}
dir->i_sb = sb;
@@ -424,7 +423,6 @@ static int ubifs_finddir(struct super_block *sb, char
*dirname,
err = PTR_ERR(dent);
goto out;
}
-
file->f_pos = key_hash_flash(c, &dent->key);
file->private_data = dent;
This hunk should be probably droped.
@@ -463,6 +461,7 @@ out:
out_free:
kfree(file->private_data);
Now question is why is file->private_data ever assigned as it seems nothing
works with it.
Good catch.
Do we need file and dentry at all in the function?
Unfortunately the file cannot be compiled on x86 cf.
https://lists.denx.de/pipermail/u-boot/2017-November/312166.html
Best regards
Heinrich
+out_nomem:
free(file);
free(dentry);
free(dir);
--
2.11.0
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
