linux-kernel - [RFC] [PATCH] Fix compat space msg size limit for msgsnd/msgrcv ( Was Re: Behaviour of compat_msgsnd/compat

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] [day] [month] [year] [list]

Date:	Fri, 10 Nov 2006 17:24:47 -0800
From:	suzuki <suzuki@...ux.vnet.ibm.com>
To:	David Miller <davem@...emloft.net>, Andrew Morton <akpm@...l.org>
CC:	linux-kernel@...r.kernel.org
Subject: [RFC] [PATCH] Fix compat space msg size limit for msgsnd/msgrcv (
 Was Re: Behaviour of compat_msgsnd/compat_msgrcv calls )

[Resending]

hi,

The compat_sys_{msgsnd,msgrcv} calls cannot handle a message of size > 
(64k - sizeof(struct msgbuf)). These calls would fail with -EINVAL for 
such invocations.

This is mainly due to the difference in the layout of the msgbuf 
structure in compat space and the native space. In compat_sys_msgrcv() 
we allocate space (at most 64k, and hence the limit) on the user stack 
using compat_alloc_user_space() and use this as the msgbuf for 
sys_msgrcv(). The results are later copied IN user space using 
copy_in_user(), which is an overhead.

The attached patch introduces (as per Dave's suggestion) helper routines 
   which accepts an additional pointer to the buf for the msgbuf. Thus 
this avoids the message size limit as well as the overhead of a 
copy_in_user().

Comments ?

Thanks

Suzuki
Linux Technology Centre
IBM Systems & Technology Labs.




Suzuki K P wrote:
> Corrected patch for some coding style errs..
> 
> Comments ?
> 
> Thanks
> 
> Suzuki
> 
> Suzuki K P wrote:
> 
>> Suzuki K P wrote:
>>
>>>
>>> -- Original Post ---
>>>
>>>> Hi,
>>>>
>>>> I have a question regarding the behaviour of the comapt_msgsnd/ 
>>>> compat_msgrcv ()s. Don't know if this has been discussed already or 
>>>> if as I could not find any threads in the archives. Please bear with 
>>>> me if this is really a stupid question.
>>>>
>>>>  The maximum length of the message that can be sent or received in 
>>>> any of those functions above is MAXBUF-(sizeof (struct msgbuf)), 
>>>> where MAXBUF is 64k.
>>>>
>>>> ipc/compat.c : compat_msgrcv()
>>>>         if (second < 0 || (second >= MAXBUF - sizeof(struct msgbuf)))
>>>>                           ^^^^^^
>>>>                 return -EINVAL;
>>>>
>>>> Is this limit due to the buffer allocation in user space as below ?
>>>>
>>>>  And the way we are doing this is by allocating a buffer of msgsize 
>>>> on the userspace stack using compat_alloc_user_space() instead of 
>>>> using the buffer provided by the user and later copying the result 
>>>> back to the user buffer.
>>>>
>>>>>
>>>>> Is there any specific reason behind this ? Can't we just use the 
>>>>> user buffer directly instead of doing an additional copy_in_user ?
>>>>> ie,
>>>>>     err = sys_msgrcv(first, uptr, second, msgtyp, third);
>>>>
>>>>
>>>>
>>>>
>>>>
>>> -- Dave suggested --
>>>
>>>> It's the cleanest way to deal with the difference in
>>>> "struct msgbuf" layout between native and compat userspace.
>>>>
>>>> I guess we could make some common do_sys_msgrcv() function
>>>> that passed in a pointer to the "msgbuf" and the buffer
>>>> seperately.
>>>
>>>
>>>
>>>
>>> Dave,
>>>
>>> I have attached a patch which does the same here. It introduces
>>> do_msgrcv()/ do_msgsnd() routines to service the sys_msgxxx variants.
>>> The do_msgxxx variants accepts an additional "mtext" parameter along
>>> with the sys_msgxxx paramters.
>>> i.e,
>>>
>>> asmlinkage long sys_msgrcv(int msqid, struct msgbuf __user *msgp,
>>>                 size_t msgsz, long msgtyp, int msgflg)
>>> {
>>>           return do_msgrcv(msqid, msgp, msgp->mtext, msgsz, msgtyp,
>>>                  msgflg);
>>> }
>>>
>>> Comments ?
>>>
>>> Thanks,
>>>
>>> -Suzuki
>>>
>>>
>>>
>>>
>>>
>>>
>>>
> 
> ------------------------------------------------------------------------

View attachment "fix-compat-msg-size.diff" of type "text/x-patch" (4861 bytes)