[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a0550a96-a7db-60d7-c4ac-86be8c8dd275@suse.com>
Date: Tue, 5 Nov 2019 10:14:01 +0100
From: Jiri Slaby <jslaby@...e.com>
To: Or Cohen <orcohen@...oaltonetworks.com>
Cc: Nicolas Pitre <nico@...xnic.net>,
Greg KH <gregkh@...uxfoundation.org>, textshell@...uujin.de,
Daniel Vetter <daniel.vetter@...ll.ch>, sam@...nborg.org,
mpatocka@...hat.com, ghalat@...hat.com,
linux-kernel@...r.kernel.org, jwilk@...lk.net,
Nadav Markus <nmarkus@...oaltonetworks.com>,
syzkaller@...glegroups.com
Subject: Re: Bug report - slab-out-of-bounds in vcs_scr_readw
On 05. 11. 19, 10:03, Or Cohen wrote:
> @Nicolas Pitre - I agree with you, "vcs_size" may return a negative
> error code, so the patch is correct but as @jslaby@...e.com said it
> won't fix the issue.
> In my debugging session, "vcs_size" returns a positive integer ( 8000
> decimal ) and the bug still triggers.
>
> Maybe it's related to the following logic in "vcs_size"? ( not sure
> about that.. )
>
> 221 if (use_attributes(inode)) {
> 222 if (use_unicode(inode))
> 223 return -EOPNOTSUPP;
> 224 size = 2*size + HEADER_SIZE;
> 225 } else if (use_unicode(inode))
> 226 size *= 4;
> 227 return size;
>
> Why in the case of "use_unicode(inode)" size is multiplied by 4 and
> not 2? ( as we can see in line 224 )
Because unicode uses 4 bytes. The issue is that there is no handling for
unicode in vcs_write at all. (Compare with vcs_read.)
thanks,
--
js
suse labs
Powered by blists - more mailing lists