eep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
>
> --
> You received this message because you are subscribed
gt; header is big enough to contain an Ethernet header. Otherwise
> > eth_hdr(skb)->h_source might access invalid data.
> >
> Forgot to Cc Alexander :/
> Sorry...
> BTW, thanks for your first analysis.
Thank you!
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erik
#syz fix: sctp: handle two v4 addrs comparison in sctp_inet6_cmp_addr
glegroups.com.
> >
> > syzbot will keep track of this bug report. See:
> > https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> > syzbot.
> > syzbot can test patches for this bug, for details see:
> > https://goo.gl/tpsmEJ#testing-patches
> --
> You received this message because you are subscribed to the Google Groups
"syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
https://groups.google.com/d/msgid/syzkaller-bugs/CADvbK_cGes4gorUa2Y8PSkL4qF4WetC2eo3PFvEYd1xbRiSihQ%40mail.gmail.com
.
> For more options, visit https://groups.google.com/d/optout.
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
KMSAN reports use of uninitialized memory in the case when |alen| is
smaller than sizeof(struct sockaddr_nl), and therefore |nladdr| isn't
fully copied from the userspace.
Signed-off-by: Alexander Potapenko <gli...@google.com>
Fixes: 1da177e4c3f41524 ("Linux-2.6.12-rc2")
---
KMSAN reports use of uninitialized memory in the case when |alen| is
smaller than sizeof(struct netlink_sock), and therefore |nladdr| isn't
fully copied from the userspace.
Signed-off-by: Alexander Potapenko <gli...@google.com>
Fixes: 1da177e4c3f41524 ("Linux-2.6.12-rc2")
On Thu, Mar 8, 2018 at 4:33 PM, Michael S. Tsirkin <m...@redhat.com> wrote:
> On Thu, Mar 08, 2018 at 02:37:17PM +0100, Alexander Potapenko wrote:
>> KMSAN reported a use of uninit memory in vhost_net_buf_unproduce()
>> while trying to access n->vqs[
On Thu, Mar 8, 2018 at 4:45 PM, Eric Dumazet <eric.duma...@gmail.com> wrote:
>
>
> On 03/08/2018 07:20 AM, Alexander Potapenko wrote:
>>
>> On Thu, Mar 8, 2018 at 4:15 PM, Eric Dumazet <eric.duma...@gmail.com>
>> wrote:
>>>
>>>
On Thu, Mar 8, 2018 at 4:15 PM, Eric Dumazet <eric.duma...@gmail.com> wrote:
>
>
> On 03/08/2018 05:37 AM, Alexander Potapenko wrote:
>>
>> KMSAN reported a use of uninit memory in vhost_net_buf_unproduce()
>> while trying to acces
553
do_sys_open+0x6ad/0x9c0 fs/open.c:1059
SYSC_openat+0xc7/0xe0 fs/open.c:1086
SyS_openat+0x63/0x90 fs/open.c:1080
do_syscall_64+0x2f1/0x450 arch/x86/entry/common.c:287
==
Signed-off-by: Alexander Potapenko <gli...@google.com>
---
/x86/entry/entry_64.S:245
==
Apparently pfkey_sendmsg reads skb past the end of the buffer copied
from the userspace.
Could someone please take a look?
Thanks,
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann
On Thu, Oct 26, 2017 at 4:56 PM, Alexander Potapenko <gli...@google.com> wrote:
> On Thu, Oct 26, 2017 at 4:52 PM, Eric Dumazet <eduma...@google.com> wrote:
>> On Thu, Oct 26, 2017 at 7:47 AM, Eric Dumazet <eduma...@google.com> wrote:
>>> On Thu, Oct 26, 2017
> per-protocol handlers run.
>>>>
>>>> Note that leaks like this are mitigated by building with
>>>> CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=y
>>>>
>>>> Reported-by: Alexander Potapenko <gli...@google.com>
>>>> Cc: "David
On Thu, Oct 26, 2017 at 4:52 PM, Eric Dumazet <eduma...@google.com> wrote:
> On Thu, Oct 26, 2017 at 7:47 AM, Eric Dumazet <eduma...@google.com> wrote:
>> On Thu, Oct 26, 2017 at 7:20 AM, Alexander Potapenko <gli...@google.com>
>> wrote:
>>> On Thu, Oc
On Thu, Oct 26, 2017 at 2:51 PM, Alexander Potapenko <gli...@google.com> wrote:
> Hi David, Eric,
>
> I've changed KMSAN instrumentation a bit and it's now reporting a new
> error (see below) when I SSH into a VM.
I've double-checked the old instrumentation and found a bu
pv4/tcp_ipv4.c:1483
tcp_v4_rcv+0x3de0/0x4ab0 net/ipv4/tcp_ipv4.c:1763
ip_local_deliver_finish+0x6bb/0xcb0 net/ipv4/ip_input.c:216
NF_HOOK ./include/linux/netfilter.h:248
...
==
--
Alexander Potapenko
Software Engineer
Google Germany G
(, 0, sizeof(struct ifreq));
strcpy((char*)_name, "gre0");
req.ifr_flags = IFF_UP | IFF_MULTICAST;
ioctl(tun_fd, TUNSETIFF, );
ioctl(sock, SIOCSIFFLAGS, "gre0");
write(tun_fd, "hi", 0);
return 0;
}
======
Sign
On Wed, Sep 27, 2017 at 3:26 PM, 'Eric Dumazet' via syzkaller
<syzkal...@googlegroups.com> wrote:
> On Wed, Sep 27, 2017 at 5:58 AM, Alexander Potapenko <gli...@google.com>
> wrote:
>> On Wed, Sep 27, 2017 at 2:45 PM, Eric Dumazet <eric.duma...@gmail.com> wrote:
&
tun->flags & TUN_TYPE_MASK) {
>> case IFF_TUN:
>> if (tun->flags & IFF_NO_PI) {
>> - switch (skb->data[0] & 0xf0) {
>> - case 0x40:
>> + u8 ip_proto = skb->len ? (skb->data[0] >&g
(, 0, sizeof(struct ifreq));
strcpy((char*)_name, "gre0");
req.ifr_flags = IFF_UP | IFF_MULTICAST;
ioctl(tun_fd, TUNSETIFF, );
ioctl(sock, SIOCSIFFLAGS, "gre0");
write(tun_fd, "hi", 0);
return 0;
}
======
Sign
ive a positive value (16 in our case)
regardless of what tipc_receive_from_sock() returns.
Second, the branch at
http://elixir.free-electrons.com/linux/v4.8/source/net/tipc/server.c#L288
is never taken.
WBR,
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 Münc
On Tue, Sep 26, 2017 at 5:02 PM, 'Eric Dumazet' via syzkaller
<syzkal...@googlegroups.com> wrote:
> On Tue, Sep 26, 2017 at 7:53 AM, Alexander Potapenko <gli...@google.com>
> wrote:
>> KMSAN (https://github.com/google/kmsan) reported accessing uninitialized
>> sk
(, 0, sizeof(struct ifreq));
strcpy((char*)_name, "gre0");
req.ifr_flags = IFF_UP | IFF_MULTICAST;
ioctl(tun_fd, TUNSETIFF, );
ioctl(sock, SIOCSIFFLAGS, "gre0");
write(tun_fd, "hi", 0);
return 0;
}
======
Sign
.c:292
==
Signed-off-by: Alexander Potapenko <gli...@google.com>
Reviewed-by: Xin Long <lucien@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leit...@gmail.com>
---
v3: set flowinfo between port and addr to ease code review.
v2 is id
.c:292
==
Signed-off-by: Alexander Potapenko <gli...@google.com>
Reviewed-by: Xin Long <lucien@gmail.com>
---
v2 is identical to v1, resending per request by Marcelo Ricardo Leitner.
---
net/sctp/ipv6.c | 2 ++
1 file changed, 2 insertions(+)
dif
On Mon, Jul 17, 2017 at 12:35 PM, Alexander Potapenko <gli...@google.com> wrote:
> KMSAN reported use of uninitialized memory in skb_set_hash_from_sk(),
> which originated from the TCP request socket created in
>
().
Signed-off-by: Alexander Potapenko <gli...@google.com>
Fixes: 58d607d3e52f ("tcp: provide skb->hash to synack packets")
---
net/ipv4/syncookies.c | 1 +
net/ipv6/syncookies.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/net/ipv4/syncookies.c b/net/ipv4/syncookies.c
On Fri, Jul 14, 2017 at 7:54 PM, David Miller <da...@davemloft.net> wrote:
> From: Alexander Potapenko <gli...@google.com>
> Date: Fri, 14 Jul 2017 19:33:54 +0200
>
>> On Fri, Jul 14, 2017 at 7:23 PM, David Miller <da...@davemloft.net> wrote:
>>> Fr
On Fri, Jul 14, 2017 at 7:04 PM, Neal Cardwell <ncardw...@google.com> wrote:
> On Fri, Jul 14, 2017 at 12:54 PM, Alexander Potapenko <gli...@google.com>
> wrote:
>> KMSAN reported use of uninitialized memory in skb_set_hash_from_sk(),
>> which originated from
On Fri, Jul 14, 2017 at 7:23 PM, David Miller <da...@davemloft.net> wrote:
> From: Alexander Potapenko <gli...@google.com>
> Date: Fri, 14 Jul 2017 18:33:01 +0200
>
>> On Fri, Jul 14, 2017 at 5:58 PM, David Miller <da...@davemloft.net> wrote:
>>> Fr
process_backlog+0x667/0xba0 net/core/dev.c:4866
napi_poll net/core/dev.c:5268
net_rx_action+0xc95/0x1590 net/core/dev.c:5333
__do_softirq+0x485/0x942 kernel/softirq.c:284
==
Signed-off-by: Alexander Potapenko <gli...@google.
_from_SYSCALL_64+0x0/0x6a arch/x86/entry/entry_64.S:246
======
Signed-off-by: Alexander Potapenko <gli...@google.com>
---
v3: fix compilation
v2: per comment from David Miller, make sure the whole iterator->length
f
On Fri, Jul 14, 2017 at 5:58 PM, David Miller <da...@davemloft.net> wrote:
> From: Alexander Potapenko <gli...@google.com>
> Date: Fri, 14 Jul 2017 12:03:29 +0200
>
>> v2: per comment from David Miller, make sure the whole iterator->length
>> fits i
_from_SYSCALL_64+0x0/0x6a arch/x86/entry/entry_64.S:246
======
Signed-off-by: Alexander Potapenko <gli...@google.com>
---
v2: per comment from David Miller, make sure the whole iterator->length
fits into the remaining
On Thu, Jul 13, 2017 at 8:32 PM, David Miller <da...@davemloft.net> wrote:
> From: Alexander Potapenko <gli...@google.com>
> Date: Thu, 13 Jul 2017 20:10:34 +0200
>
>> diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
>> index a9519a06a23b..f13632e
On Thu, Jul 13, 2017 at 8:14 PM, Alexander Potapenko <gli...@google.com> wrote:
> On Thu, Jul 13, 2017 at 8:10 PM, Alexander Potapenko <gli...@google.com>
> wrote:
>> If the iterator (|pos.p| or |err|) has already reached the end of
>> chunk, we shouldn't access it
On Thu, Jul 13, 2017 at 8:10 PM, Alexander Potapenko <gli...@google.com> wrote:
> If the iterator (|pos.p| or |err|) has already reached the end of
> chunk, we shouldn't access iterator->length.
>
> This bug has been detected by KMSAN. For the following pair of system
return_from_SYSCALL_64+0x0/0x6a arch/x86/entry/entry_64.S:246
==
Signed-off-by: Alexander Potapenko <gli...@google.com>
---
include/net/sctp/sctp.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/net/sctp/sct
On Tue, Jun 6, 2017 at 10:36 PM, David Miller <da...@davemloft.net> wrote:
> From: Alexander Potapenko <gli...@google.com>
> Date: Tue, 6 Jun 2017 15:56:54 +0200
>
>> KMSAN reported a use of uninitialized memory in dev_set_alias(),
>> which was caused by callin
KMSAN reported a use of uninitialized memory in dev_set_alias(),
which was caused by calling strlcpy() (which in turn called strlen())
on the user-supplied non-terminated string.
Signed-off-by: Alexander Potapenko <gli...@google.com>
---
v4: dropped the comment at all, as suggested by Yury
On Thu, Jun 1, 2017 at 4:04 PM, Yury Norov <yno...@caviumnetworks.com> wrote:
> On Thu, Jun 01, 2017 at 03:50:33PM +0200, Alexander Potapenko wrote:
>> On Thu, Jun 1, 2017 at 3:47 PM, Yury Norov <yno...@caviumnetworks.com> wrote:
>> > On Thu, Jun 01, 2017 at 02:38:2
On Thu, Jun 1, 2017 at 3:47 PM, Yury Norov <yno...@caviumnetworks.com> wrote:
> On Thu, Jun 01, 2017 at 02:38:29PM +0200, Alexander Potapenko wrote:
>> KMSAN reported a use of uninitialized memory in dev_set_alias(),
>> which was caused by calling strlcpy() (which
KMSAN reported a use of uninitialized memory in dev_set_alias(),
which was caused by calling strlcpy() (which in turn called strlen())
on the user-supplied non-terminated string.
Signed-off-by: Alexander Potapenko <gli...@google.com>
---
v3: removed the multi-line comment
v2: fixed an off-
On Wed, May 31, 2017 at 5:10 PM, David Miller <da...@davemloft.net> wrote:
> From: Alexander Potapenko <gli...@google.com>
> Date: Wed, 31 May 2017 10:56:47 +0200
>
>> Hi David,
>>
>> I've noticed that the upstream patch:
>
KMSAN reported a use of uninitialized memory in dev_set_alias(),
which was caused by calling strlcpy() (which in turn called strlen())
on the user-supplied non-terminated string.
Signed-off-by: Alexander Potapenko <gli...@google.com>
---
v2: fixed an off-by-one error spotted by Dmitry
KMSAN reported a use of uninitialized memory in dev_set_alias(),
which was caused by calling strlcpy() (which in turn called strlen())
on the user-supplied non-terminated string.
Signed-off-by: Alexander Potapenko <gli...@google.com>
---
For the record, here is the KMSAN
). Did I mess it up somehow?
Alex
On Wed, May 24, 2017 at 9:32 PM, David Miller <da...@davemloft.net> wrote:
> From: Alexander Potapenko <gli...@google.com>
> Date: Tue, 23 May 2017 13:20:28 +0200
>
>> rtnl_fdb_dump() failed to check the result of nlmsg_parse(), which
eak to the userspace directly.
The bug has been detected with KMSAN and syzkaller.
Signed-off-by: Alexander Potapenko <gli...@google.com>
---
For the record, here is the KMSAN report:
==
BUG: KMSAN: use of unitialized memory in rtnl
raw_send_hdrinc() and rawv6_send_hdrinc() expect that the buffer copied
from the userspace contains the IPv4/IPv6 header, so if too few bytes are
copied, parts of the header may remain uninitialized.
This bug has been detected with KMSAN.
Signed-off-by: Alexander Potapenko <gli...@google.
On Wed, Apr 26, 2017 at 3:00 PM, Alexander Potapenko <gli...@google.com> wrote:
> On Wed, Apr 26, 2017 at 10:54 AM, Alexander Potapenko <gli...@google.com>
> wrote:
>> On Tue, Apr 25, 2017 at 7:55 PM, David Miller <da...@davemloft.net> wrote:
>>> From:
On Wed, Apr 26, 2017 at 10:54 AM, Alexander Potapenko <gli...@google.com> wrote:
> On Tue, Apr 25, 2017 at 7:55 PM, David Miller <da...@davemloft.net> wrote:
>> From: Alexander Potapenko <gli...@google.com>
>> Date: Tue, 25 Apr 2017 15:18:27 +0200
>>
>>
On Tue, Apr 25, 2017 at 7:55 PM, David Miller <da...@davemloft.net> wrote:
> From: Alexander Potapenko <gli...@google.com>
> Date: Tue, 25 Apr 2017 15:18:27 +0200
>
>> rawv6_send_hdrinc() expects that the buffer copied from the userspace
>> contains the IPv6 heade
een detected with KMSAN.
Signed-off-by: Alexander Potapenko <gli...@google.com>
---
The previous versions of this patch were called "net/packet: initialize
val in packet_getsockopt()"
v3: - change patch summary, return -EINVAL for optlen < sizeof(int)
v2: - if len < sizeof(
On Tue, Apr 25, 2017 at 6:32 PM, David Miller <da...@davemloft.net> wrote:
> From: Alexander Potapenko <gli...@google.com>
> Date: Tue, 25 Apr 2017 18:27:04 +0200
>
>> On Tue, Apr 25, 2017 at 5:44 PM, David Miller <da...@davemloft.net> wrote:
>>> Fr
On Tue, Apr 25, 2017 at 5:44 PM, David Miller <da...@davemloft.net> wrote:
> From: Alexander Potapenko <gli...@google.com>
> Date: Mon, 24 Apr 2017 14:59:14 +0200
>
>> In the case getsockopt() is called with PACKET_HDRLEN and optlen < 4
>> |val| remains unin
rawv6_send_hdrinc() expects that the buffer copied from the userspace
contains the IPv6 header, so if too few bytes are copied parts of the
header may remain uninitialized.
This bug has been detected with KMSAN.
Signed-off-by: Alexander Potapenko <gli...@google.com>
---
For the record, the
ure optlen is not less than sizeof(int).
This bug has been detected with KMSAN.
Signed-off-by: Alexander Potapenko <gli...@google.com>
---
v2: - if len < sizeof(int), make it 0
KMSAN report below:
==
BUG: KMSAN: use of unitia
has been detected with KMSAN.
Signed-off-by: Alexander Potapenko <gli...@google.com>
---
KMSAN report below:
==
BUG: KMSAN: use of unitialized memory in packet_getsockopt+0xb9b/0xbe0
inter: 0
CPU: 0 PID: 1036 Comm: probe Tain
In the case udp_sk(sk)->pending is AF_INET6, udpv6_sendmsg() would
jump to do_append_data, skipping the initialization of sockc.tsflags.
Fix the problem by moving sockc.tsflags initialization earlier.
The bug was detected with KMSAN.
Signed-off-by: Alexander Potapenko <gli...@goog
KMSAN reports a use of uninitialized memory in put_cmsg() because
msg.msg_flags in recvfrom haven't been initialized properly.
The flag values don't affect the result on this path, but it's still a
good idea to initialize them explicitly.
Signed-off-by: Alexander Potapenko <gli...@google.
On Tue, Mar 7, 2017 at 3:26 PM, Eric Dumazet <eric.duma...@gmail.com> wrote:
> On Tue, 2017-03-07 at 14:58 +0100, Alexander Potapenko wrote:
>> KMSAN (KernelMemorySanitizer, a new error detection tool) reports use
>> of uninitialized memory in put_cmsg()):
>
> I would
On Tue, Mar 7, 2017 at 3:23 PM, Dmitry Vyukov <dvyu...@google.com> wrote:
> On Tue, Mar 7, 2017 at 2:58 PM, Alexander Potapenko <gli...@google.com> wrote:
>> KMSAN (KernelMemorySanitizer, a new error detection tool) reports use
>> of unini
, 0, 0, 0};
socklen_t addrlen = sizeof(sockaddr);
recvfrom(sock, ibuf, 0, 0, , );
}
int main()
{
int pid = fork();
if (!pid) {
child();
return 0;
}
int status = 0;
while (waitpid(pid, , __WALL) != pid) {}
return 0;
}
=
mine the port, or e.g. pass them further to
sel_netnode_find(), which uses them to calculate a hash.
Signed-off-by: Alexander Potapenko <gli...@google.com>
---
Changes since v1:
- fixed patch description
- fixed addrlen tests to match those in inet_bind() and inet6_bind()
(pe
mine the port, or e.g. pass them further to
sel_netnode_find(), which uses them to calculate a hash.
Signed-off-by: Alexander Potapenko <gli...@google.com>
---
security/selinux/hooks.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/security/selinux/hooks.c b/security/selinux
On Fri, Mar 3, 2017 at 6:23 PM, Alexander Potapenko <gli...@google.com> wrote:
> KMSAN (KernelMemorySanitizer, a new error detection tool) reports use of
> uninitialized memory in packet_bind_spkt():
Should be "in selinux_socket_bind()", will fix in
nclude/linux/mtd/map.h |8 +-
> include/linux/typecheck.h|7 +-
> include/net/netlink.h| 36 +-
> lib/Kconfig.debug |9 +-
> lib/Kconfi
On Fri, Mar 3, 2017 at 3:30 PM, Arnd Bergmann <a...@arndb.de> wrote:
> On Fri, Mar 3, 2017 at 2:55 PM, Alexander Potapenko <gli...@google.com> wrote:
>> On Fri, Mar 3, 2017 at 2:50 PM, Andrey Ryabinin <aryabi...@virtuozzo.com>
>> wrote:
>
>>>>
d to the Google Groups
> "kasan-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kasan-dev+unsubscr...@googlegroups.com.
> To post to this group, send email to kasan-...@googlegroups.com.
> To view this discussion o
y of that non-terminated
buffer.
Signed-off-by: Alexander Potapenko <gli...@google.com>
---
Changes since v3:
- addressed comments by Eric Dumazet (avoid using constants,
use memcpy() instead of strncpy())
---
net/packet/af_packet.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletio
return -EINVAL;
> - strlcpy(name, uaddr->sa_data, sizeof(name));
> + memcpy(name, uaddr->sa_data, sizeof(uaddr->sa_data));
> + name[sizeof(uaddr->sa_data)] = 0;
>
> return packet_do_bind(sk, name, 0, pkt_sk(sk)->num);
> }
>
SGTM. Shal
On Tue, Feb 28, 2017 at 2:33 PM, Eric Dumazet <eric.duma...@gmail.com> wrote:
> On Tue, 2017-02-28 at 14:17 +0100, Alexander Potapenko wrote:
>> KMSAN (KernelMemorySanitizer, a new error detection tool) reports use of
>> uninitialized memor
y of that non-terminated
buffer.
Signed-off-by: Alexander Potapenko <gli...@google.com>
---
Changes since v2:
- per offline comment from Dmitry Vyukov use sizeof(name) - 1
instead of a constant.
net/packet/af_packet.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
y of that non-terminated
buffer.
Signed-off-by: Alexander Potapenko <gli...@google.com>
---
Changes since v1:
- copy no more than 14 bytes
---
net/packet/af_packet.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 2bd
y of that non-terminated
buffer.
Signed-off-by: Alexander Potapenko <gli...@google.com>
---
net/packet/af_packet.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 2bd0d1949312..1e7992f3e0a8 100644
--- a/net/packe
y of that non-terminated
buffer.
Signed-off-by: Alexander Potapenko <gli...@google.com>
---
net/packet/af_packet.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 2bd0d1949312..1e7992f3e0a8 100644
--- a/net/packe
On Tue, Mar 15, 2016 at 2:46 PM, David Laight <david.lai...@aculab.com> wrote:
> From: Alexander Potapenko
>> Sent: 15 March 2016 09:04
>> According to IEEE Std 1003.1, 2013, sending data to a SOCK_SEQPACKET
>> socketpair with MSG_NOSIGNAL flag set must result in
On Tue, Mar 15, 2016 at 2:20 PM, Eric Dumazet <eric.duma...@gmail.com> wrote:
> On Tue, 2016-03-15 at 10:03 +0100, Alexander Potapenko wrote:
>> According to IEEE Std 1003.1, 2013, sending data to a SOCK_SEQPACKET
>> socketpair with MSG_NOSIGNAL flag set must result in a SIG
Done, thanks for your response!
On Mon, Mar 14, 2016 at 8:19 PM, David Miller <da...@davemloft.net> wrote:
> From: Alexander Potapenko <gli...@google.com>
> Date: Wed, 9 Mar 2016 15:10:23 +0100
>
>> According to IEEE Std 1003.1, 2013, sending data to a S
ock stream
Killed by SIGPIPE
$ ./sock seqpacket nosignal
sendmsg: Broken pipe
$ ./sock stream nosignal
sendmsg: Broken pipe
Signed-off-by: Alexander Potapenko <gli...@google.com>
---
net/unix/af_unix.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/net/unix/
According to IEEE Std 1003.1, 2013, sending data to a SOCK_SEQPACKET
socketpair with MSG_NOSIGNAL flag set must result in a SIGPIPE if the
socket is no longer connected.
Signed-off-by: Alexander Potapenko <gli...@google.com>
---
I used the following program to check the kernel be
81 matches
Mail list logo
