* net/sctp: GPF in sctp_addr_id2transport
@ 2017-02-07 9:42 Dmitry Vyukov
2017-02-07 11:09 ` Marcelo Ricardo Leitner
0 siblings, 1 reply; 3+ messages in thread
From: Dmitry Vyukov @ 2017-02-07 9:42 UTC (permalink / raw)
To: Vladislav Yasevich, Neil Horman, David Miller, linux-sctp, netdev,
Eric Dumazet, Marcelo Ricardo Leitner, LKML
Cc: syzkaller
Hello,
The following program triggers GPF in sctp_addr_id2transport:
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include <string.h>
#include <stdint.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <linux/in.h>
#include <linux/sctp.h>
int main()
{
int sock = socket(AF_INET6, SOCK_SEQPACKET, IPPROTO_SCTP);
struct sctp_paddrinfo info;
memset(&info, 0, sizeof(info));
int sz = sizeof(info);
getsockopt(sock, IPPROTO_SCTP, SCTP_GET_PEER_ADDR_INFO, &info, &sz);
return 0;
}
general protection fault: 0000 [#1] SMP KASAN
Modules linked in:
CPU: 2 PID: 2923 Comm: a.out Not tainted 4.10.0-rc7+ #212
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff880066db2400 task.stack: ffff88006b9b8000
RIP: 0010:sctp_addr_id2transport+0xb7/0x350 net/sctp/socket.c:242
RSP: 0018:ffff88006b9bf1d0 EFLAGS: 00010207
RAX: 0000000000000000 RBX: ffff880067e1f000 RCX: 0000000000000017
RDX: dffffc0000000000 RSI: ffff88006b9bf2b4 RDI: 00000000000000bc
RBP: ffff88006b9bf268 R08: ffffed000d737e69 R09: ffffed000d737e69
R10: 0000000000000000 R11: ffffed000d737e68 R12: ffff88006b9bf2b4
R13: ffff88006b9bf200 R14: 1ffff1000d737e3c R15: ffff88006b9bf240
FS: 0000000001f3b880(0000) GS:ffff88006d100000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000004b2120 CR3: 000000006940a000 CR4: 00000000001406e0
Call Trace:
sctp_getsockopt_peer_addr_info+0x211/0x620 net/sctp/socket.c:4628
sctp_getsockopt+0x2813/0x66a0 net/sctp/socket.c:6503
sock_common_getsockopt+0x95/0xd0 net/core/sock.c:2685
SYSC_getsockopt net/socket.c:1819 [inline]
SyS_getsockopt+0x240/0x380 net/socket.c:1801
entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x436dea
RSP: 002b:00007ffe2c6c19c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000037
RAX: ffffffffffffffda RBX: 0000000000401780 RCX: 0000000000436dea
RDX: 000000000000000f RSI: 0000000000000084 RDI: 0000000000000003
RBP: 0000000000000000 R08: 00007ffe2c6c19d8 R09: 0000000000000004
R10: 00007ffe2c6c19e0 R11: 0000000000000246 R12: 00000000004002b0
R13: 00007ffe2c6c1b88 R14: 0000000000000002 R15: 0000000000000000
Code: 8d 6f c0 e8 7c 78 fa ff 4c 89 e9 48 8d b8 bc 00 00 00 48 ba 00
00 00 00 00 fc ff df 48 c1 e9 03 c6 04 11 00 48 89 f9 48 c1 e9 03 <0f>
b6 0c 11 48 89 fa 83 e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85
RIP: sctp_addr_id2transport+0xb7/0x350 net/sctp/socket.c:242 RSP:
ffff88006b9bf1d0
---[ end trace afb2edc8308e52f6 ]---
On commit 8b1b41ee74f9712c355d66dc105bbea663ae0afd.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: net/sctp: GPF in sctp_addr_id2transport
2017-02-07 9:42 net/sctp: GPF in sctp_addr_id2transport Dmitry Vyukov
@ 2017-02-07 11:09 ` Marcelo Ricardo Leitner
2017-02-07 11:56 ` Xin Long
0 siblings, 1 reply; 3+ messages in thread
From: Marcelo Ricardo Leitner @ 2017-02-07 11:09 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Vladislav Yasevich, Neil Horman, David Miller, linux-sctp, netdev,
Eric Dumazet, LKML, syzkaller, Xin Long
On Tue, Feb 07, 2017 at 10:42:38AM +0100, Dmitry Vyukov wrote:
> Hello,
>
> The following program triggers GPF in sctp_addr_id2transport:
>
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include <string.h>
> #include <stdint.h>
> #include <sys/types.h>
> #include <sys/socket.h>
> #include <linux/in.h>
> #include <linux/sctp.h>
>
> int main()
> {
> int sock = socket(AF_INET6, SOCK_SEQPACKET, IPPROTO_SCTP);
> struct sctp_paddrinfo info;
> memset(&info, 0, sizeof(info));
> int sz = sizeof(info);
> getsockopt(sock, IPPROTO_SCTP, SCTP_GET_PEER_ADDR_INFO, &info, &sz);
> return 0;
> }
>
...
> RIP: 0010:sctp_addr_id2transport+0xb7/0x350 net/sctp/socket.c:242
...
> sctp_getsockopt_peer_addr_info+0x211/0x620 net/sctp/socket.c:4628
> sctp_getsockopt+0x2813/0x66a0 net/sctp/socket.c:6503
> sock_common_getsockopt+0x95/0xd0 net/core/sock.c:2685
> SYSC_getsockopt net/socket.c:1819 [inline]
> SyS_getsockopt+0x240/0x380 net/socket.c:1801
> entry_SYSCALL_64_fastpath+0x1f/0xc2
Xin, I believe 6f29a1306131 ("sctp: sctp_addr_id2transport should verify
the addr before looking up assoc") introduced this issue.
As info is all 0'ed in this test,
+ struct sctp_af *af = sctp_get_af_specific(addr->ss_family);
will return NULL, and then boom at:
+ if (sctp_verify_addr(sk, laddr, af->sockaddr_len))
^^^^
Marcelo
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: net/sctp: GPF in sctp_addr_id2transport
2017-02-07 11:09 ` Marcelo Ricardo Leitner
@ 2017-02-07 11:56 ` Xin Long
0 siblings, 0 replies; 3+ messages in thread
From: Xin Long @ 2017-02-07 11:56 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: Dmitry Vyukov, Vladislav Yasevich, Neil Horman, David Miller,
linux-sctp, netdev, Eric Dumazet, LKML, syzkaller
On Tue, Feb 7, 2017 at 7:09 PM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> On Tue, Feb 07, 2017 at 10:42:38AM +0100, Dmitry Vyukov wrote:
>> Hello,
>>
>> The following program triggers GPF in sctp_addr_id2transport:
>>
>> // autogenerated by syzkaller (http://github.com/google/syzkaller)
>> #include <string.h>
>> #include <stdint.h>
>> #include <sys/types.h>
>> #include <sys/socket.h>
>> #include <linux/in.h>
>> #include <linux/sctp.h>
>>
>> int main()
>> {
>> int sock = socket(AF_INET6, SOCK_SEQPACKET, IPPROTO_SCTP);
>> struct sctp_paddrinfo info;
>> memset(&info, 0, sizeof(info));
>> int sz = sizeof(info);
>> getsockopt(sock, IPPROTO_SCTP, SCTP_GET_PEER_ADDR_INFO, &info, &sz);
>> return 0;
>> }
>>
> ...
>> RIP: 0010:sctp_addr_id2transport+0xb7/0x350 net/sctp/socket.c:242
> ...
>> sctp_getsockopt_peer_addr_info+0x211/0x620 net/sctp/socket.c:4628
>> sctp_getsockopt+0x2813/0x66a0 net/sctp/socket.c:6503
>> sock_common_getsockopt+0x95/0xd0 net/core/sock.c:2685
>> SYSC_getsockopt net/socket.c:1819 [inline]
>> SyS_getsockopt+0x240/0x380 net/socket.c:1801
>> entry_SYSCALL_64_fastpath+0x1f/0xc2
>
> Xin, I believe 6f29a1306131 ("sctp: sctp_addr_id2transport should verify
> the addr before looking up assoc") introduced this issue.
>
> As info is all 0'ed in this test,
> + struct sctp_af *af = sctp_get_af_specific(addr->ss_family);
> will return NULL, and then boom at:
> + if (sctp_verify_addr(sk, laddr, af->sockaddr_len))
> ^^^^
>
The issue is caused by users passed a address with family = 0,
and af is NULL there.
I already have a patch for this, will post it soon. Thanks.
> Marcelo
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-02-07 11:56 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-02-07 9:42 net/sctp: GPF in sctp_addr_id2transport Dmitry Vyukov
2017-02-07 11:09 ` Marcelo Ricardo Leitner
2017-02-07 11:56 ` Xin Long
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox