netdev - Re: [PATCH] af_unix: Allow Unix sockets to raise SIGURG

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]

Date:   Fri, 29 Jan 2021 13:54:43 -0800
From:   Shoaib Rao <rao.shoaib@...cle.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     "Matthew Wilcox (Oracle)" <willy@...radead.org>,
        linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
        netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
        andy.rudoff@...el.com
Subject: Re: [PATCH] af_unix: Allow Unix sockets to raise SIGURG


On 1/29/21 1:18 PM, Jakub Kicinski wrote:
> On Fri, 29 Jan 2021 12:44:44 -0800 Shoaib Rao wrote:
>> On 1/29/21 12:18 PM, Jakub Kicinski wrote:
>>> On Fri, 29 Jan 2021 12:10:21 -0800 Shoaib Rao wrote:
>>>> The code does not care about the size of data -- All it does is that if
>>>> MSG_OOB is set it will deliver the signal to the peer process
>>>> irrespective of the length of the data (which can be zero length). Let's
>>>> look at the code of unix_stream_sendmsg() It does the following (sent is
>>>> initialized to zero)
>>> Okay. Let me try again. AFAICS your code makes it so that data sent
>>> with MSG_OOB is treated like any other data. It just sends a signal.
>> Correct.
>>> So you're hijacking the MSG_OOB to send a signal, because OOB also
>>> sends a signal.
>> Correct.
>>>    But there is nothing OOB about the data itself.
>> Correct.
>>>    So
>>> I'm asking you to make sure that there is no data in the message.
>> Yes I can do that.
>>> That way when someone wants _actual_ OOB data on UNIX sockets they
>>> can implement it without breaking backwards compatibility of the
>>> kernel uAPI.
>> I see what you are trying to achieve. However it may not work.
>>
>> Let's assume that __actual__ OOB data has been implemented. An
>> application sends a zero length message with MSG_OOB, after that it
>> sends some data (not suppose to be OOB data). How is the receiver going
>> to differentiate if the data an OOB or not.
> THB I've never written any application which would use OOB, so in
> practice IDK. But from kernel code and looking at man pages when
> OOBINLINE is not set for OOB data to be received MSG_OOB has to be
> set in the recv syscall.

Thinking a little more about your suggestion, I think it can work but 
the application will have to do some more work to differentiate. I would 
prefer it would not have to. Anyways, I will re-submit the patch with 
the zero length check.

Thanks a lot for your comments,

Shoaib

>
>> We could use a different flag (MSG_SIGURG) or implement the _actual_ OOB
>> data semantics (If anyone is interested in it). MSG_SIGURG could be a
>> generic flag that just sends SIGURG irrespective of the length of the data.
> No idea on the SIGURG parts :)