(sk->sk_state != TCP_CLOSE)
>>> goto out_unlock;
>>
>>
>> Makes sense, it should prevent a concurrent caller adding the socket
>> into bind table
>> twice after passing __l2tp_ip_bind_lookup() check.
>
> Yes, and the __l2tp_ip_bind_lookup() call is also racy. But, by
> properly checking the SOCK_ZAPPED flag, we probably can remove this
> call entirely.
>
> For now, I only wanted to make sure the issue was well identified. I'll
> submit a more complete patch for net (with protected SOCK_ZAPPED check
> in l2tp_ip_connect() too).
>
The patch fixes the issues both for l2tp_ip and l2tp_ip6
Tested-by: Baozeng Ding <splovi...@gmail.com>
Best Regards,
Baozeng Ding
On 2016/11/10 13:48, Xin Long wrote:
> On Sat, Oct 15, 2016 at 4:28 PM, Baozeng Ding <splovi...@gmail.com> wrote:
>> Hello Xin Long,
>>
>> On 2016/10/14 19:13, Xin Long wrote:
>>> On Sat, Aug 20, 2016 at 3:51 PM, Baozeng Ding <splovi...@gmail.com>
^
88002f163c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
88002f163d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
======
Best Regards,
Baozeng Ding
On 2016/10/17 3:53, Co
7 3:50, Cong Wang wrote:
> On Sun, Oct 16, 2016 at 8:07 AM, Baozeng Ding <splovi...@gmail.com> wrote:
>> Hello,
>> While running syzkaller fuzzer I have got the following use-after-free
>> bug in l2tp_ip6_close. The kernel version is 4.8.0+ (on Oct 7 commit
>> d
It fixes the issue for me.
Tested-by: Baozeng Ding <splovi...@gmail.com>
On 2016/10/17 17:54, Baozeng Ding wrote:
> Applied the patch to my test tree. I will tell you the result a few days
> later. Thank you.
>
> On 2016/10/17 2:50, Cong Wang wrote:
>> On Sun, Oct 16,
It fixes the issue for me.
Tested-by: Baozeng Ding <splovi...@gmail.com>
On 2016/10/17 17:54, Baozeng Ding wrote:
> Applied the patch to my test tree. I will tell you the result a few days
> later. Thank you.
>
> On 2016/10/17 2:50, Cong Wang wrote:
>> On Sun, Oct 16,
^
88002f163c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
88002f163d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
======
Best Regards,
Baozeng Ding
On 2016/10/17 3:53, Cong Wang wrote:
> On Sun, Oct 16, 2016 at 6:46 AM, Baoze
Applied the patch to my test tree. I will tell you the result a few days later.
Thank you.
On 2016/10/17 2:50, Cong Wang wrote:
> On Sun, Oct 16, 2016 at 6:34 AM, Baozeng Ding <splovi...@gmail.com> wrote:
>> Possible unsafe locking scenario:
>>
>>C
fc fc fc fc fc fc fc fc fc fc
>8800081b0e80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
^
8800081b0f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
8800081b0f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==
Best Regards,
Baozeng Ding
fc fc fc fc fc
88002f3fe100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>88002f3fe180: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
^
88002f3fe200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
88002f3fe280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
Thansk && Best Regards,
Baozeng Ding
fb fb
==========
Thanks && Best Regards,
Baozeng Ding
58/0x240 net/socket.c:1721
[] entry_SYSCALL_64_fastpath+0x23/0xc6
Thanks && Best Regards,
Baozeng Ding
Hello Xin Long,
On 2016/10/14 19:13, Xin Long wrote:
> On Sat, Aug 20, 2016 at 3:51 PM, Baozeng Ding <splovi...@gmail.com> wrote:
>> Hello all,
>> The following program triggers stack-out-of-bounds in memcmp. The kernel
>> version is 4
]+1)<<3, ptr);
I debuged using printk and got some values of opt as the following, which may
help locate the root cause of the bug. Thanks.
[85564.842733] degug: opt->iif is 0xe21c
[85564.842737] degug: opt->ra is 0x121c
[85564.842741] degug: opt->dst0 is 0xe111
Best Regards,
Baozeng Ding
)0x1;
*(uint64_t*)0x20f77025 = (uint64_t)0x13;
*(uint32_t*)0x20f7702d = (uint32_t)0x6;
*(uint32_t*)0x20f77031 = (uint32_t)0xfe00;
*(uint8_t*)0x20f77035 = (uint8_t)0x8000;
*(uint8_t*)0x20f77036 = (uint8_t)0xfff8;
sendmmsg(fd, (struct mmsghdr *)0x202e1fc8ul, 0x1ul, 0x1ul);
return 0;
}
Best Regards,
Baozeng Ding
Before calling the nla_data function, make sure the argument is not null.
Fix potential null pointer dereference vulnerability for this.
Signed-off-by: Baozeng Ding <splovi...@gmail.com>
---
net/tipc/netlink_compat.c | 12
1 file changed, 12 insertions(+)
diff --git a/ne
On 2016/5/26 23:06, Eric Dumazet wrote:
> On Thu, 2016-05-26 at 22:48 +0800, Baozeng Ding wrote:
>> Hi all,
>> I've got the following report use-after-free in netlink_sock_destruct while
>> running syzkaller.
>> Unfortunately no reproducer.The kernel versio
Hi all,
I've got the following report use-after-free in netlink_sock_destruct while
running syzkaller.
Unfortunately no reproducer.The kernel version is 4.6 (May 15, on commit
2dcd0af568b0cf583645c8a317dd12e344b1c72a). Thanks.
==
Fix a logic error to avoid potential null pointer dereference.
Signed-off-by: Baozeng Ding <splovi...@gmail.com>
---
net/ieee802154/nl802154.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index ca207db..1
Fix a logic error to avoid potential null pointer dereference.
Signed-off-by: Baozeng Ding <splovi...@gmail.com>
---
net/ieee802154/nl802154.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index ca207db..1
Before calling the nla_parse_nested function, make sure the pointer to the
attribute is not null. This patch fixes several potential null pointer
dereference vulnerabilities in the tipc netlink functions.
Signed-off-by: Baozeng Ding <splovi...@gmail.com>
---
v2: declare local variable as r
Before calling the nla_parse_nested function, its third argument should be
checked to make sure it is not null. This patch fixes several potential
null pointer dereference vulnerabilities in the tipc netlink functions.
Signed-off-by: Baozeng Ding <splovi...@gmail.com>
---
ne
Before calling the nla_parse_nested function, make sure the pointer to
the attribute is not null. This patch fixes several potential null
pointer dereference vulnerabilities in the tipc netlink functions.
Signed-off-by: Baozeng Ding <splovi...@gmail.com>
---
net/tipc/netlink_compat.c
Before calling the nla_parse_nested funciton, its third argument should be
checked to make sure it is not null. This patch fixes several potential
null pointer dereference vulnerability in the tipc netlink functions.
Signed-off-by: Baozeng Ding <splovi...@gmail.com>
---
ne
027900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>880038027980: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
^
ffff880038027a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
880038027a80: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc
==
Best Regards,
Baozeng Ding
y state around the buggy address:
880038027880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
880038027900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
880038027980: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
^
880038027a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
880038027a80: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc
==
Best Regards,
Baozeng Ding
2d/0x50 net/socket.c:2157
[] entry_SYSCALL_64_fastpath+0x23/0xc1
arch/x86/entry/entry_64.S:207
Memory state around the buggy address:
880036ae7880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
880036ae7900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>880036ae7980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
880036ae7a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
880036ae7a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==
Best Regards,
Baozeng Ding
On 2016/5/15 1:13, Eric Dumazet wrote:
On Sat, 2016-05-14 at 23:22 +0800, Baozeng Ding wrote:
Hello all,
The following program triggers NULL-ptr dereference in
tipc_nl_publ_dump. The kernel version is 4.6.0-rc7+ (on May 13 commit
1410b74e4061e05a5d2bffb1f99829efce27c8a9). Thanks
Hello all,
The following program triggers NULL-ptr dereference in
tipc_nl_publ_dump. The kernel version is 4.6.0-rc7+ (on May 13 commit
1410b74e4061e05a5d2bffb1f99829efce27c8a9). Thanks.
--
netlink: 1 bytes leftover
On 2016/3/28 10:35, Baozeng Ding wrote:
On 2016/3/28 6:25, Jozsef Kadlecsik wrote:
On Mon, 28 Mar 2016, Jozsef Kadlecsik wrote:
On Sun, 27 Mar 2016, Baozeng Ding wrote:
The following program triggers stack-out-of-bounds in tcp_packet. The
kernel version is 4.5 (on Mar 16 commit
;
*(uint32_t*)0x2001502c = (uint32_t)0x0;
*(uint32_t*)0x20015030 = (uint32_t)0x100;
*(uint32_t*)0x20015034 = (uint32_t)0x3;
sendto(sock_dup, (void *)0x2001504ful, 0xe8ul, 0x880ul, (struct
sockaddr *)0x20015000ul, 0x1cul);
return 0;
}
Best Regards,
Baozeng Ding
xe8\x18\x3d\x7f\x0e\x2f\xe9\x06\xf9\xb6\xcc\x60\xcc\x38\x6c\x9a\x78\xa7\x7c\x61",
1037);
getsockopt(sock_dup, IPPROTO_IP, 0x81, (void *)0x2bf3ul,
(socklen_t *)0x20003000ul);
return 0;
}
Best Regards,
Baozeng Ding
nd the buggy address:
880064e21680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
880064e21700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>880064e21780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff880064e21800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
880064e21880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==
Best Regards,
Baozeng Ding
node+0x3b0/0x3b0
kernel/kernel/kthread.c:285
Memory state around the buggy address:
88043ef6e200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
88043ef6e280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>88043ef6e300: fc fc fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
88043ef6e380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
88043ef6e400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
Best Regards,
Baozeng Ding
34 matches
Mail list logo
