On Thu, Jun 6, 2024 at 10:27 AM Xuan Zhuo wrote:
>
> On Thu, 6 Jun 2024 10:20:21 +0200, Alexander Potapenko
> wrote:
> > > Could you try this?
> >
> > Hi Xuan,
> >
> > What kernel revision does this patch apply to? I tried it against
> > v6.10-r
>
> Could you try this?
(resending without HTML, sorry for inconvenience).
Hi Xuan,
What kernel revision does this patch apply to? I tried it against
v6.10-rc2, and only the first hunk applied.
However this seems to fix the problem, at least the kernel boots
without warnings now.
> Thanks.
>
> d
On Tue, Jun 4, 2024 at 6:07 PM Ilya Leoshkevich wrote:
>
> On Thu, 2023-08-10 at 20:30 +0800, Xuan Zhuo wrote:
> > If the vq is the premapped mode, use the sg_dma_address() directly.
> >
> > Signed-off-by: Xuan Zhuo
> > ---
> > drivers/virtio/virtio_ring.c | 19 +--
> > 1 file ch
On Wed, May 27, 2020 at 6:58 PM Alexei Starovoitov
wrote:
>
> On Wed, May 27, 2020 at 8:52 AM Alexander Potapenko wrote:
> >
> > This basically means that BPF's output register was uninitialized when
> > ___bpf_prog_run() returned.
> >
> > When I replace
On Tue, Dec 18, 2018 at 3:36 PM Alexander Potapenko wrote:
>
> On Thu, Dec 13, 2018 at 3:54 PM Daniel Borkmann wrote:
> >
> > On 12/13/2018 02:18 PM, Daniel Borkmann wrote:
> > > On 12/13/2018 01:24 PM, Alexander Potapenko wrote:
> > >> On Thu, Dec 13
fore copying it to user memory in sctp_v4_addr_to_user(), as
> sctp_v6_addr_to_user() does.
>
> Reported-by: syzbot+86b5c7c236a22616a...@syzkaller.appspotmail.com
> Signed-off-by: Xin Long
Tested-by: Alexander Potapenko
> ---
> net/sctp/protocol.c | 1 +
> 1 file changed, 1
On Mon, Jan 14, 2019 at 10:56 AM Xin Long wrote:
>
> On Mon, Jan 14, 2019 at 5:34 PM Alexander Potapenko wrote:
> >
> > On Mon, Dec 10, 2018 at 9:56 AM Xin Long wrote:
> > >
> > > On Thu, Dec 6, 2018 at 8:08 PM Marcelo Ricardo Leitner
> > > wrote:
On Mon, Dec 10, 2018 at 9:56 AM Xin Long wrote:
>
> On Thu, Dec 6, 2018 at 8:08 PM Marcelo Ricardo Leitner
> wrote:
> >
> > On Thu, Dec 06, 2018 at 11:36:08AM +0100, Alexander Potapenko wrote:
> > > On Wed, Dec 5, 2018 at 8:31 PM syzbot
> > > wrote:
> &
On Thu, Dec 13, 2018 at 3:54 PM Daniel Borkmann wrote:
>
> On 12/13/2018 02:18 PM, Daniel Borkmann wrote:
> > On 12/13/2018 01:24 PM, Alexander Potapenko wrote:
> >> On Thu, Dec 13, 2018 at 1:20 PM Michal Kubecek wrote:
> >>> On Thu, Dec 13, 2018 at 12:59
On Thu, Dec 13, 2018 at 2:18 PM Daniel Borkmann wrote:
>
> On 12/13/2018 01:24 PM, Alexander Potapenko wrote:
> > On Thu, Dec 13, 2018 at 1:20 PM Michal Kubecek wrote:
> >> On Thu, Dec 13, 2018 at 12:59:36PM +0100, Michal Kubecek wrote:
> >>> On Thu, Dec 13, 20
On Thu, Dec 13, 2018 at 1:20 PM Michal Kubecek wrote:
>
> On Thu, Dec 13, 2018 at 12:59:36PM +0100, Michal Kubecek wrote:
> > On Thu, Dec 13, 2018 at 12:00:59PM +0100, Alexander Potapenko wrote:
> > > Hi BPF maintainers,
> > >
> > > some time ago KMSAN foun
On Thu, Dec 13, 2018 at 12:06 PM Eric Dumazet wrote:
>
>
>
> On 12/13/2018 03:00 AM, Alexander Potapenko wrote:
> > Hi BPF maintainers,
> >
> > some time ago KMSAN found an issue in BPF code which we decided to
> > suppress at that point, but now I'
ter
values like it's done here:
https://github.com/google/kmsan/commit/813c0f3d45ebfa321d70b4b06cc054518dd1d90d
?
Thanks,
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 -numme
On Thu, Dec 6, 2018 at 12:06 PM Marcelo Ricardo Leitner
wrote:
>
> On Thu, Dec 06, 2018 at 11:36:08AM +0100, Alexander Potapenko wrote:
> > On Wed, Dec 5, 2018 at 8:31 PM syzbot
> > wrote:
> > >
> > > Hello,
> > >
> > > syzbot
ill 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 subsc
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
---
> > This bug is generated by a bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for more information about syzbot.
> > syzbot engineers can be reached at syzkal...@googlegroups.com.
> >
> > syzbot will keep track of this bug report. See:
> > https://goo.gl/
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
Fixes: 1da177e4c3f41524 ("Linux-2.6.12-rc2")
---
v2: fixed a typo spotted
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
Fixes: 1da177e4c3f41524 ("Linux-2.6.12-rc2")
---
net/netlink/af_netli
On Thu, Mar 8, 2018 at 4:33 PM, Michael S. Tsirkin 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[VHOST_
On Thu, Mar 8, 2018 at 4:45 PM, Eric Dumazet wrote:
>
>
> On 03/08/2018 07:20 AM, Alexander Potapenko wrote:
>>
>> On Thu, Mar 8, 2018 at 4:15 PM, Eric Dumazet
>> wrote:
>>>
>>>
>>>
>>> On 03/08/2018 05:37 AM, Alexander Potapenko
On Thu, Mar 8, 2018 at 4:15 PM, Eric Dumazet 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 access n-&g
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
---
drivers/vhost/net.c | 1 +
m_SYSCALL_64+0x0/0x6a arch/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
On Thu, Oct 26, 2017 at 4:56 PM, Alexander Potapenko wrote:
> On Thu, Oct 26, 2017 at 4:52 PM, Eric Dumazet wrote:
>> On Thu, Oct 26, 2017 at 7:47 AM, Eric Dumazet wrote:
>>> On Thu, Oct 26, 2017 at 7:20 AM, Alexander Potapenko
>>> wrote:
>>>> On
are mitigated by building with
>>>> CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=y
>>>>
>>>> Reported-by: Alexander Potapenko
>>>> Cc: "David S. Miller"
>>>> Cc: netdev@vger.kernel.org
>>>> Signed-off-by: Kees Cook
>>&
On Thu, Oct 26, 2017 at 4:52 PM, Eric Dumazet wrote:
> On Thu, Oct 26, 2017 at 7:47 AM, Eric Dumazet wrote:
>> On Thu, Oct 26, 2017 at 7:20 AM, Alexander Potapenko
>> wrote:
>>> On Thu, Oct 26, 2017 at 2:51 PM, Alexander Potapenko
>>> wrote:
>>>>
On Thu, Oct 26, 2017 at 2:51 PM, Alexander Potapenko 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 bug in it,
which
_do_rcv+0xa6a/0xcd0 net/ipv4/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 E
memset(&req, 0, sizeof(struct ifreq));
strcpy((char*)&req.ifr_name, "gre0");
req.ifr_flags = IFF_UP | IFF_MULTICAST;
ioctl(tun_fd, TUNSETIFF, &req);
ioctl(sock, SIOCSIFFLAGS, "gre0");
write(tun_fd, "hi", 0);
return 0;
On Wed, Sep 27, 2017 at 3:26 PM, 'Eric Dumazet' via syzkaller
wrote:
> On Wed, Sep 27, 2017 at 5:58 AM, Alexander Potapenko
> wrote:
>> On Wed, Sep 27, 2017 at 2:45 PM, Eric Dumazet wrote:
>>> On Wed, 2017-09-27 at 05:42 -0700, Eric Dumazet wrote:
>>>
; case IFF_TUN:
>> if (tun->flags & IFF_NO_PI) {
>> - switch (skb->data[0] & 0xf0) {
>> - case 0x40:
>> + u8 ip_proto = skb->len ? (skb->data[0] >> 4) : 0;
>
> And na
memset(&req, 0, sizeof(struct ifreq));
strcpy((char*)&req.ifr_name, "gre0");
req.ifr_flags = IFF_UP | IFF_MULTICAST;
ioctl(tun_fd, TUNSETIFF, &req);
ioctl(sock, SIOCSIFFLAGS, "gre0");
write(tun_fd, "hi", 0);
return 0;
he user appears to receive 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-M
On Tue, Sep 26, 2017 at 5:02 PM, 'Eric Dumazet' via syzkaller
wrote:
> On Tue, Sep 26, 2017 at 7:53 AM, Alexander Potapenko
> wrote:
>> KMSAN (https://github.com/google/kmsan) reported accessing uninitialized
>> skb->data[0] in the case the s
memset(&req, 0, sizeof(struct ifreq));
strcpy((char*)&req.ifr_name, "gre0");
req.ifr_flags = IFF_UP | IFF_MULTICAST;
ioctl(tun_fd, TUNSETIFF, &req);
ioctl(sock, SIOCSIFFLAGS, "gre0");
write(tun_fd, "hi", 0);
return 0;
.c:292
==
Signed-off-by: Alexander Potapenko
Reviewed-by: Xin Long
Acked-by: Marcelo Ricardo Leitner
---
v3: set flowinfo between port and addr to ease code review.
v2 is identical to v1, resending per request by Marcelo Ricardo Leitner.
---
net/sctp/ipv6.c | 2
.c:292
==
Signed-off-by: Alexander Potapenko
Reviewed-by: Xin Long
---
v2 is identical to v1, resending per request by Marcelo Ricardo Leitner.
---
net/sctp/ipv6.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
On Mon, Jul 17, 2017 at 12:35 PM, Alexander Potapenko wrote:
> KMSAN reported use of uninitialized memory in skb_set_hash_from_sk(),
> which originated from the TCP request socket created in
> cookie_v6_check():
>
> =
().
Signed-off-by: Alexander Potapenko
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
index 0905cf04c2a4..03ad8778c395
On Fri, Jul 14, 2017 at 7:54 PM, David Miller wrote:
> From: Alexander Potapenko
> Date: Fri, 14 Jul 2017 19:33:54 +0200
>
>> On Fri, Jul 14, 2017 at 7:23 PM, David Miller wrote:
>>> From: Alexander Potapenko
>>> Date: Fri, 14 Jul 2017 18:33:01 +0200
>>
On Fri, Jul 14, 2017 at 7:04 PM, Neal Cardwell wrote:
> On Fri, Jul 14, 2017 at 12:54 PM, Alexander Potapenko
> wrote:
>> KMSAN reported use of uninitialized memory in skb_set_hash_from_sk(),
>> which originated from the TCP request socket created in
>> cookie_v6_che
On Fri, Jul 14, 2017 at 7:23 PM, David Miller wrote:
> From: Alexander Potapenko
> Date: Fri, 14 Jul 2017 18:33:01 +0200
>
>> On Fri, Jul 14, 2017 at 5:58 PM, David Miller wrote:
>>> From: Alexander Potapenko
>>> Date: Fri, 14 Jul 2017 12:03:29 +0200
>>&g
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
---
net/ipv6
0 arch/x86/entry/common.c:285
return_from_SYSCALL_64+0x0/0x6a arch/x86/entry/entry_64.S:246
======
Signed-off-by: Alexander Potapenko
---
v3: fix compilation
v2: per comment from David Miller, make sure the whole iterator->length
fits into the re
On Fri, Jul 14, 2017 at 5:58 PM, David Miller wrote:
> From: Alexander Potapenko
> Date: Fri, 14 Jul 2017 12:03:29 +0200
>
>> v2: per comment from David Miller, make sure the whole iterator->length
>> fits into the remaining buffer.
>
> Please compile and
0 arch/x86/entry/common.c:285
return_from_SYSCALL_64+0x0/0x6a arch/x86/entry/entry_64.S:246
======
Signed-off-by: Alexander Potapenko
---
v2: per comment from David Miller, make sure the whole iterator->length
fits into the remaining buffer.
On Thu, Jul 13, 2017 at 8:32 PM, David Miller wrote:
> From: Alexander Potapenko
> 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..f13632ee33f0 100644
>> --- a/include/net/sctp/sctp.
On Thu, Jul 13, 2017 at 8:14 PM, Alexander Potapenko wrote:
> On Thu, Jul 13, 2017 at 8:10 PM, Alexander Potapenko
> wrote:
>> If the iterator (|pos.p| or |err|) has already reached the end of
>> chunk, we shouldn't access iterator->length.
>>
>> This b
On Thu, Jul 13, 2017 at 8:10 PM, Alexander Potapenko 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
> calls:
>
>
x130 arch/x86/entry/common.c:285
return_from_SYSCALL_64+0x0/0x6a arch/x86/entry/entry_64.S:246
======
Signed-off-by: Alexander Potapenko
---
include/net/sctp/sctp.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/net/sctp/sctp.h b/include/ne
On Tue, Jun 6, 2017 at 10:36 PM, David Miller wrote:
> From: Alexander Potapenko
> Date: Tue, 6 Jun 2017 15:56:54 +0200
>
>> KMSAN reported a use of uninitialized memory in dev_set_alias(),
>> which was caused by calling strlcpy() (which in turn called strlen())
>&g
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
---
v4: dropped the comment at all, as suggested by Yury Norov
v3: removed the
On Thu, Jun 1, 2017 at 4:04 PM, Yury Norov 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 wrote:
>> > On Thu, Jun 01, 2017 at 02:38:29PM +0200, Alexander Potapenko wrote:
>> >> KMSAN r
On Thu, Jun 1, 2017 at 3:47 PM, Yury Norov 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 in turn called strlen())
>> on
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
---
v3: removed the multi-line comment
v2: fixed an off-by-one error spotted by
On Wed, May 31, 2017 at 5:10 PM, David Miller wrote:
> From: Alexander Potapenko
> Date: Wed, 31 May 2017 10:56:47 +0200
>
>> Hi David,
>>
>> I've noticed that the upstream patch:
>> https://github.com/torvalds/linux/commit/0ff50e83b5122e836ca492fefb11656
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
---
v2: fixed an off-by-one error spotted by Dmitry Vyukov
For the record, here
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
---
For the record, here is the KMSAN report
hat information). Did I mess it up somehow?
Alex
On Wed, May 24, 2017 at 9:32 PM, David Miller wrote:
> From: Alexander Potapenko
> Date: Tue, 23 May 2017 13:20:28 +0200
>
>> rtnl_fdb_dump() failed to check the result of nlmsg_parse(), which led
>> to contents of |ifm| being
k to the userspace directly.
The bug has been detected with KMSAN and syzkaller.
Signed-off-by: Alexander Potapenko
---
For the record, here is the KMSAN report:
==
BUG: KMSAN: use of unitialized memory in rtnl_fdb_dump+0x5dc/0x100
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
---
The previous
On Wed, Apr 26, 2017 at 3:00 PM, Alexander Potapenko wrote:
> On Wed, Apr 26, 2017 at 10:54 AM, Alexander Potapenko
> wrote:
>> On Tue, Apr 25, 2017 at 7:55 PM, David Miller wrote:
>>> From: Alexander Potapenko
>>> Date: Tue, 25 Apr 2017 15:18:27 +0200
>&g
On Wed, Apr 26, 2017 at 10:54 AM, Alexander Potapenko wrote:
> On Tue, Apr 25, 2017 at 7:55 PM, David Miller wrote:
>> From: Alexander Potapenko
>> Date: Tue, 25 Apr 2017 15:18:27 +0200
>>
>>> rawv6_send_hdrinc() expects that the buffer copied from the userspace
&g
On Tue, Apr 25, 2017 at 7:55 PM, David Miller wrote:
> From: Alexander Potapenko
> Date: Tue, 25 Apr 2017 15:18:27 +0200
>
>> 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
een detected with KMSAN.
Signed-off-by: Alexander Potapenko
---
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(int), make it 0
---
net
On Tue, Apr 25, 2017 at 6:32 PM, David Miller wrote:
> From: Alexander Potapenko
> Date: Tue, 25 Apr 2017 18:27:04 +0200
>
>> On Tue, Apr 25, 2017 at 5:44 PM, David Miller wrote:
>>> From: Alexander Potapenko
>>> Date: Mon, 24 Apr 2017 14:59:14 +0200
>>&g
On Tue, Apr 25, 2017 at 5:44 PM, David Miller wrote:
> From: Alexander Potapenko
> Date: Mon, 24 Apr 2017 14:59:14 +0200
>
>> In the case getsockopt() is called with PACKET_HDRLEN and optlen < 4
>> |val| remains uninitialized and the syscall may behave differently
>>
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
---
For the record, the KMSAN report
e
|val| and ensure optlen is not less than sizeof(int).
This bug has been detected with KMSAN.
Signed-off-by: Alexander Potapenko
---
v2: - if len < sizeof(int), make it 0
KMSAN report below:
==
BUG: KMSAN: use of
val|.
This bug has been detected with KMSAN.
Signed-off-by: Alexander Potapenko
---
KMSAN report below:
==
BUG: KMSAN: use of unitialized memory in packet_getsockopt+0xb9b/0xbe0
inter: 0
CPU: 0 PID: 1036 Comm: probe Tainted: GB
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
---
For the record, h
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
---
C
On Tue, Mar 7, 2017 at 3:26 PM, Eric Dumazet 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 prefer that you do not put t
On Tue, Mar 7, 2017 at 3:23 PM, Dmitry Vyukov wrote:
> On Tue, Mar 7, 2017 at 2:58 PM, Alexander Potapenko wrote:
>> KMSAN (KernelMemorySanitizer, a new error detection tool) reports use
>> of uninitialized mem
AF_NETLINK, 0, 0, 0};
socklen_t addrlen = sizeof(sockaddr);
recvfrom(sock, ibuf, 0, 0, &sockaddr, &addrlen);
}
int main()
{
int pid = fork();
if (!pid) {
child();
return 0;
}
int status = 0;
while (waitpid(pid, &status, __WALL) != pid) {}
d ones, to determine the port, or e.g. pass them further to
sel_netnode_find(), which uses them to calculate a hash.
Signed-off-by: Alexander Potapenko
---
Changes since v1:
- fixed patch description
- fixed addrlen tests to match those in inet_bind() and inet6_bind()
(per comment from Eric D
d ones, to determine the port, or e.g. pass them further to
sel_netnode_find(), which uses them to calculate a hash.
Signed-off-by: Alexander Potapenko
---
security/selinux/hooks.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
ind
On Fri, Mar 3, 2017 at 6:23 PM, Alexander Potapenko 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 the ne
| 58 ++-
> include/linux/mtd/map.h |8 +-
> include/linux/typecheck.h|7 +-
> include/net/netlink.h| 36 +-
> lib/Kconfig.debug |9 +-
>
On Fri, Mar 3, 2017 at 3:30 PM, Arnd Bergmann wrote:
> On Fri, Mar 3, 2017 at 2:55 PM, Alexander Potapenko wrote:
>> On Fri, Mar 3, 2017 at 2:50 PM, Andrey Ryabinin
>> wrote:
>
>>>> @@ -416,6 +416,17 @@ static __always_inline void
>>>> __write_on
ogle 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 on the web visit
> htt
) on the kernel copy of that non-terminated
buffer.
Signed-off-by: Alexander Potapenko
---
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 deletions(-)
diff
- 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. Shall I send the updated patch?
On Tue, Feb 28, 2017 at 2:33 PM, Eric Dumazet wrote:
> On Tue, 2017-02-28 at 14:17 +0100, Alexander Potapenko wrote:
>> KMSAN (KernelMemorySanitizer, a new error detection tool) reports use of
>> uninitialized memory in p
) on the kernel copy of that non-terminated
buffer.
Signed-off-by: Alexander Potapenko
---
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 a/net
) on the kernel copy of that non-terminated
buffer.
Signed-off-by: Alexander Potapenko
---
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 2bd0d194931
) on the kernel copy of that non-terminated
buffer.
Signed-off-by: Alexander Potapenko
---
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/packet/af_packe
) on the kernel copy of that non-terminated
buffer.
Signed-off-by: Alexander Potapenko
---
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/packet/af_packe
On Tue, Mar 15, 2016 at 2:46 PM, David Laight 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 a SIGPIPE if the
>> so
On Tue, Mar 15, 2016 at 2:20 PM, Eric Dumazet 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 SIGPIPE if the
>> socket i
Done, thanks for your response!
On Mon, Mar 14, 2016 at 8:19 PM, David Miller wrote:
> From: Alexander Potapenko
> Date: Wed, 9 Mar 2016 15:10:23 +0100
>
>> According to IEEE Std 1003.1, 2013, sending data to a SOCK_SEQPACKET
>> socketpair with MSG_NOSIGNAL flag set must r
led by SIGPIPE
$ ./sock stream
Killed by SIGPIPE
$ ./sock seqpacket nosignal
sendmsg: Broken pipe
$ ./sock stream nosignal
sendmsg: Broken pipe
Signed-off-by: Alexander Potapenko
---
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
---
I used the following program to check the kernel behavior
95 matches
Mail list logo
