lkml.org 
[lkml]   [2017]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
Subject[PATCH 2/2] adfs: use 'unsigned' types for memcpy length
Date
After commit 62d1034f53e3 ("fortify: use WARN instead of BUG for now"), we
get a warning in adfs about a possible buffer overflow:

In function 'memcpy',
inlined from '__adfs_dir_put' at fs/adfs/dir_f.c:318:2,
inlined from 'adfs_f_update' at fs/adfs/dir_f.c:403:2:
include/linux/string.h:305:4: error: call to '__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter
__read_overflow2();
^~~~~~~~~~~~~~~~~~

The warning is correct in the sense that a negative 'pos' argument
to the function would have that result. However, this is not a bug,
as we know the position is always positive (in fact, between 5
and 2007, inclusive) when the function gets called.

Changing the variable to a unsigned type avoids the problem. I decided
to use 'unsigned int' for the position in the directory and the block
number, as they are both counting things, but use size_t for the
offset and length that get passed into memcpy. This shuts up the
warning.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
fs/adfs/dir_f.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/adfs/dir_f.c b/fs/adfs/dir_f.c
index 0fbfd0b04ae0..dab3595a1ecc 100644
--- a/fs/adfs/dir_f.c
+++ b/fs/adfs/dir_f.c
@@ -283,11 +283,12 @@ __adfs_dir_get(struct adfs_dir *dir, int pos, struct object_info *obj)
}

static int
-__adfs_dir_put(struct adfs_dir *dir, int pos, struct object_info *obj)
+__adfs_dir_put(struct adfs_dir *dir, unsigned int pos, struct object_info *obj)
{
struct super_block *sb = dir->sb;
struct adfs_direntry de;
- int thissize, buffer, offset;
+ unsigned int buffer;
+ size_t thissize, offset;

buffer = pos >> sb->s_blocksize_bits;

--
2.9.0
\
 
 \ /
  Last update: 2017-08-01 14:06    [W:0.101 / U:6.600 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site