linux-kernel - Re: [PATCH] jfs: Fix fortify moan in symlink

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <63d4e019-8671-4f4c-f95d-acb8b2ab559b@oracle.com>
Date:   Thu, 27 Oct 2022 17:18:29 -0500
From:   Dave Kleikamp <dave.kleikamp@...cle.com>
To:     "Dr. David Alan Gilbert" <linux@...blig.org>,
        Kees Cook <keescook@...omium.org>
Cc:     jfs-discussion@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
        syzbot+5fc38b2ddbbca7f5c680@...kaller.appspotmail.com
Subject: Re: [PATCH] jfs: Fix fortify moan in symlink

Applied.

Thanks,
Shaggy

On 10/24/22 1:49PM, Dr. David Alan Gilbert wrote:
> * Kees Cook (keescook@...omium.org) wrote:
>> On Sat, Oct 22, 2022 at 09:39:14PM +0100, linux@...blig.org wrote:
>>> From: "Dr. David Alan Gilbert" <linux@...blig.org>
>>>
>>> JFS has in jfs_incore.h:
>>>
>>>        /* _inline may overflow into _inline_ea when needed */
>>>        /* _inline_ea may overlay the last part of
>>>         * file._xtroot if maxentry = XTROOTINITSLOT
>>>         */
>>>        union {
>>>          struct {
>>>            /* 128: inline symlink */
>>>            unchar _inline[128];
>>>            /* 128: inline extended attr */
>>>            unchar _inline_ea[128];
>>>          };
>>>          unchar _inline_all[256];
>>>
>>> and currently the symlink code copies into _inline;
>>> if this is larger than 128 bytes it triggers a fortify warning of the
>>> form:
>>>
>>>    memcpy: detected field-spanning write (size 132) of single field
>>>       "ip->i_link" at fs/jfs/namei.c:950 (size 18446744073709551615)
>>
>> Which compiler are you using for this build?
> 
> I think that report was the same on gcc on Fedora 37 and whatever
> syzkaller was running.
> 
>> This size report (SIZE_MAX)
>> should be impossible to reach. But also, the size is just wrong --
>> i_inline is 128 bytes, not SIZE_MAX. So, the detection is working
>> (132 > 128), but the report is broken, and I can't see how...
> 
> Yeh, and led me down a blind alley for a while thinking something had
> really managed to screwup the strlen somehow.
> 
>>
>>>
>>> when it's actually OK.
>>>
>>> Copy it into _inline_all instead.
>>>
>>> Reported-by: syzbot+5fc38b2ddbbca7f5c680@...kaller.appspotmail.com
>>> Signed-off-by: Dr. David Alan Gilbert <linux@...blig.org>
>>> ---
>>>   fs/jfs/namei.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/fs/jfs/namei.c b/fs/jfs/namei.c
>>> index 9db4f5789c0ec..4fbbf88435e69 100644
>>> --- a/fs/jfs/namei.c
>>> +++ b/fs/jfs/namei.c
>>> @@ -946,7 +946,7 @@ static int jfs_symlink(struct user_namespace *mnt_userns, struct inode *dip,
>>>   	if (ssize <= IDATASIZE) {
>>>   		ip->i_op = &jfs_fast_symlink_inode_operations;
>>>   
>>> -		ip->i_link = JFS_IP(ip)->i_inline;
>>> +		ip->i_link = JFS_IP(ip)->i_inline_all;
>>>   		memcpy(ip->i_link, name, ssize);
>>>   		ip->i_size = ssize - 1;
>>>   
>>
>> Regardless, the fix looks correct to me!
>>
>> Reviewed-by: Kees Cook <keescook@...omium.org>
> 
> Thanks!
> 
> Dave
> 
>> -- 
>> Kees Cook