Fix NULL dereference in x25_recvmsg

PATCH In review Dave Jones 3 participants 9 messages Nov 2, 2011

Subsystems (3)

Networking Network drivers X.25 stack

lore

Share & tools

lore

Dave Jones

author

2011-11-02 01:53 UTC #0 lore raw

commit cb101ed2 in 3.0 introduced a bug in x25_recvmsg() When passed bogus junk from userspace, x25->neighbour can be NULL, as shown in this oops..

BUG: unable to handle kernel NULL pointer dereference at 000000000000001c
IP: [<ffffffffa05482bd>] x25_recvmsg+0x4d/0x280 [x25]
PGD 1015f3067 PUD 105072067 PMD 0 
Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
CPU 0 
Pid: 27928, comm: iknowthis Not tainted 3.1.0+ #2 Gigabyte Technology Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H
RIP: 0010:[<ffffffffa05482bd>]  [<ffffffffa05482bd>] x25_recvmsg+0x4d/0x280 [x25]
RSP: 0018:ffff88010c0b7cc8  EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff88010c0b7d78 RCX: 0000000000000c02
RDX: ffff88010c0b7d78 RSI: ffff88011c93dc00 RDI: ffff880103f667b0
RBP: ffff88010c0b7d18 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff880103f667b0
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  00007f479ce7f700(0000) GS:ffff88012a600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000000001c CR3: 000000010529e000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process iknowthis (pid: 27928, threadinfo ffff88010c0b6000, task ffff880103faa4f0)
Stack:
 0000000000000c02 0000000000000c02 ffff88010c0b7d18 ffffff958153cb37
 ffffffff8153cb60 0000000000000c02 ffff88011c93dc00 0000000000000000
 0000000000000c02 ffff88010c0b7e10 ffff88010c0b7de8 ffffffff815372c2
Call Trace:
 [<ffffffff8153cb60>] ? sock_update_classid+0xb0/0x180
 [<ffffffff815372c2>] sock_aio_read.part.10+0x142/0x150
 [<ffffffff812d6752>] ? inode_has_perm+0x62/0xa0
 [<ffffffff815372fd>] sock_aio_read+0x2d/0x40
 [<ffffffff811b05e2>] do_sync_read+0xd2/0x110
 [<ffffffff812d3796>] ? security_file_permission+0x96/0xb0
 [<ffffffff811b0a91>] ? rw_verify_area+0x61/0x100
 [<ffffffff811b103d>] vfs_read+0x16d/0x180
 [<ffffffff811b109d>] sys_read+0x4d/0x90
 [<ffffffff81657282>] system_call_fastpath+0x16/0x1b
Code: 8b 66 20 4c 8b 32 48 89 d3 48 89 4d b8 45 89 c7 c7 45 cc 95 ff ff ff 4d 85 e4 0f 84 ed 01 00 00 49 8b 84 24 18 05 00 00 4c 89 e7 
 78 1c 01 45 19 ed 31 f6 e8 d5 37 ff e0 41 0f b6 44 24 0e 41

Signed-off-by Dave Jones <[email protected]>

net/x25/af_x25.c +7 -3

index 5f03e4e..291b2e0 100644
@@ -1261,13 +1261,17 @@ static int x25_recvmsg(struct kiocb *iocb, struct socket *sock,
 	struct x25_sock *x25 = x25_sk(sk);
 	struct sockaddr_x25 *sx25 = (struct sockaddr_x25 *)msg->msg_name;
 	size_t copied;
-	int qbit, header_len = x25->neighbour->extended ?
-		X25_EXT_MIN_LEN : X25_STD_MIN_LEN;
-
+	int qbit, header_len;
 	struct sk_buff *skb;
 	unsigned char *asmptr;
 	int rc = -ENOTCONN;
 
+	if (x25->neighbour == NULL)
+		return rc;
+
+	header_len = x25->neighbour->extended ?
+		X25_EXT_MIN_LEN : X25_STD_MIN_LEN;
+
 	lock_sock(sk);
 	/*
 	 * This works for seqpacket too. The receiver has ordered the queue for

Eric Dumazet

2011-11-02 02:10 UTC #1 lore raw

Quoted 4 lines · Dave Jones

commit cb101ed2 in 3.0 introduced a bug in x25_recvmsg() When passed bogus junk from userspace, x25->neighbour can be NULL, as shown in this oops..

Your patch seems fine but :

Are you sure this bug is not present on previous kernels ?

It seems we had prior to this commit :

skb_pull(skb, x25->neighbour->extended ?

	X25_EXT_MIN_LEN : X25_STD_MIN_LEN);

Quoted 25 lines

Signed-off-by Dave Jones <[email protected]>

net/x25/af_x25.c +7 -3

index 5f03e4e..291b2e0 100644
@@ -1261,13 +1261,17 @@ static int x25_recvmsg(struct kiocb *iocb, struct socket *sock,
 	struct x25_sock *x25 = x25_sk(sk);
 	struct sockaddr_x25 *sx25 = (struct sockaddr_x25 *)msg->msg_name;
 	size_t copied;
-	int qbit, header_len = x25->neighbour->extended ?
-		X25_EXT_MIN_LEN : X25_STD_MIN_LEN;
-
+	int qbit, header_len;
 	struct sk_buff *skb;
 	unsigned char *asmptr;
 	int rc = -ENOTCONN;
 
+	if (x25->neighbour == NULL)
+		return rc;
+
+	header_len = x25->neighbour->extended ?
+		X25_EXT_MIN_LEN : X25_STD_MIN_LEN;
+
 	lock_sock(sk);

Dave Jones

author

2011-11-02 02:15 UTC #2 lore raw

Quoted 6 lines · Eric Dumazet

Quoted 4 lines · Dave Jones
commit cb101ed2 in 3.0 introduced a bug in x25_recvmsg() When passed bogus junk from userspace, x25->neighbour can be NULL, as shown in this oops..

Quoted 8 lines

Your patch seems fine but :
Are you sure this bug is not present on previous kernels ?
It seems we had prior to this commit :
skb_pull(skb, x25->neighbour->extended ?
	X25_EXT_MIN_LEN : X25_STD_MIN_LEN);

It might have been possible with a specifically crafted set of arguments.

It never showed up in testing before now, probably because we were returning from the function before we got to that skb_pull via all the other tests that get performed.

Dave

Eric Dumazet

2011-11-02 02:19 UTC #3 lore raw

Quoted 13 lines · Dave Jones

Quoted 12 lines · Eric Dumazet
Quoted 4 lines · Dave Jones
commit cb101ed2 in 3.0 introduced a bug in x25_recvmsg() When passed bogus junk from userspace, x25->neighbour can be NULL, as shown in this oops..
Your patch seems fine but :
Are you sure this bug is not present on previous kernels ?
It seems we had prior to this commit :

Quoted 9 lines

Quoted 2 lines
skb_pull(skb, x25->neighbour->extended ?
	X25_EXT_MIN_LEN : X25_STD_MIN_LEN);
It might have been possible with a specifically crafted set of arguments.
It never showed up in testing before now, probably because we were returning from the function before we got to that skb_pull via all the other tests that get performed.

neighbour is not an x25_recvmsg() argument, but related to x25 socket state.

Maybe your tests dont try to use x25_recvmsg() while socket has no neighbour...

This bug was there before the cb101ed2 commit.

Eric Dumazet

2011-11-02 02:21 UTC #4 lore raw

Quoted 24 lines · Eric Dumazet

Quoted 13 lines · Dave Jones
Quoted 12 lines · Eric Dumazet
Quoted 4 lines · Dave Jones
commit cb101ed2 in 3.0 introduced a bug in x25_recvmsg() When passed bogus junk from userspace, x25->neighbour can be NULL, as shown in this oops..
Your patch seems fine but :
Are you sure this bug is not present on previous kernels ?
It seems we had prior to this commit :
Quoted 9 lines
Quoted 2 lines
skb_pull(skb, x25->neighbour->extended ?
	X25_EXT_MIN_LEN : X25_STD_MIN_LEN);
It might have been possible with a specifically crafted set of arguments.
It never showed up in testing before now, probably because we were returning from the function before we got to that skb_pull via all the other tests that get performed.

Quoted 8 lines

neighbour is not an x25_recvmsg() argument, but related to x25 socket state.
Maybe your tests dont try to use x25_recvmsg() while socket has no neighbour...
This bug was there before the cb101ed2 commit.

Ah ok, I see now, we exited early because of

if (sk->sk_state != TCP_ESTABLISHED)

	goto out;

So yes, commit cb101ed2 is the bug origin, sorry for the noise.

Eric Dumazet

2011-11-02 02:16 UTC #5 lore raw

In reply to Dave Jones

Quoted 56 lines · Dave Jones

commit cb101ed2 in 3.0 introduced a bug in x25_recvmsg() When passed bogus junk from userspace, x25->neighbour can be NULL, as shown in this oops..

BUG: unable to handle kernel NULL pointer dereference at 000000000000001c
IP: [<ffffffffa05482bd>] x25_recvmsg+0x4d/0x280 [x25]
PGD 1015f3067 PUD 105072067 PMD 0 
Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
CPU 0 
Pid: 27928, comm: iknowthis Not tainted 3.1.0+ #2 Gigabyte Technology Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H
RIP: 0010:[<ffffffffa05482bd>]  [<ffffffffa05482bd>] x25_recvmsg+0x4d/0x280 [x25]
RSP: 0018:ffff88010c0b7cc8  EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff88010c0b7d78 RCX: 0000000000000c02
RDX: ffff88010c0b7d78 RSI: ffff88011c93dc00 RDI: ffff880103f667b0
RBP: ffff88010c0b7d18 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff880103f667b0
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  00007f479ce7f700(0000) GS:ffff88012a600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000000001c CR3: 000000010529e000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process iknowthis (pid: 27928, threadinfo ffff88010c0b6000, task ffff880103faa4f0)
Stack:
 0000000000000c02 0000000000000c02 ffff88010c0b7d18 ffffff958153cb37
 ffffffff8153cb60 0000000000000c02 ffff88011c93dc00 0000000000000000
 0000000000000c02 ffff88010c0b7e10 ffff88010c0b7de8 ffffffff815372c2
Call Trace:
 [<ffffffff8153cb60>] ? sock_update_classid+0xb0/0x180
 [<ffffffff815372c2>] sock_aio_read.part.10+0x142/0x150
 [<ffffffff812d6752>] ? inode_has_perm+0x62/0xa0
 [<ffffffff815372fd>] sock_aio_read+0x2d/0x40
 [<ffffffff811b05e2>] do_sync_read+0xd2/0x110
 [<ffffffff812d3796>] ? security_file_permission+0x96/0xb0
 [<ffffffff811b0a91>] ? rw_verify_area+0x61/0x100
 [<ffffffff811b103d>] vfs_read+0x16d/0x180
 [<ffffffff811b109d>] sys_read+0x4d/0x90
 [<ffffffff81657282>] system_call_fastpath+0x16/0x1b
Code: 8b 66 20 4c 8b 32 48 89 d3 48 89 4d b8 45 89 c7 c7 45 cc 95 ff ff ff 4d 85 e4 0f 84 ed 01 00 00 49 8b 84 24 18 05 00 00 4c 89 e7 
 78 1c 01 45 19 ed 31 f6 e8 d5 37 ff e0 41 0f b6 44 24 0e 41

Signed-off-by Dave Jones <[email protected]>

net/x25/af_x25.c +1 -3

index 5f03e4e..291b2e0 100644
@@ -1261,13 +1261,17 @@ static int x25_recvmsg(struct kiocb *iocb, struct socket *sock,
 	struct x25_sock *x25 = x25_sk(sk);
 	struct sockaddr_x25 *sx25 = (struct sockaddr_x25 *)msg->msg_name;
 	size_t copied;
-	int qbit, header_len = x25->neighbour->extended ?
-		X25_EXT_MIN_LEN : X25_STD_MIN_LEN;
-
+	int qbit, header_len;
 	struct sk_buff *skb;

net/x25/af_x25.c static int x25_recvmsg(struct kiocb *iocb, struct socket *sock, · line 1275

Quoted 10 lines

net/x25/af_x25.c +6 -0

 	unsigned char *asmptr;
 	int rc = -ENOTCONN;
 
+	if (x25->neighbour == NULL)
+		return rc;
+
+	header_len = x25->neighbour->extended ?
+		X25_EXT_MIN_LEN : X25_STD_MIN_LEN;
+
 	lock_sock(sk);

BTW, you probably want to check x25->neighbour while sk is locked, not before.

	lock_sock(sk);
	if (x25->neighbour == NULL)
		goto out;
	header_len = x25->neighbour->extended ?
		     X25_EXT_MIN_LEN : X25_STD_MIN_LEN;

Dave Jones

author

2011-11-02 02:26 UTC #6 lore raw

PATCH v2 1/1 Fix NULL dereference in x25_recvmsg

commit cb101ed2 in 3.0 introduced a bug in x25_recvmsg() When passed bogus junk from userspace, x25->neighbour can be NULL, as shown in this oops..

BUG: unable to handle kernel NULL pointer dereference at 000000000000001c
IP: [<ffffffffa05482bd>] x25_recvmsg+0x4d/0x280 [x25]
PGD 1015f3067 PUD 105072067 PMD 0 
Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
CPU 0 
Pid: 27928, comm: iknowthis Not tainted 3.1.0+ #2 Gigabyte Technology Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H
RIP: 0010:[<ffffffffa05482bd>]  [<ffffffffa05482bd>] x25_recvmsg+0x4d/0x280 [x25]
RSP: 0018:ffff88010c0b7cc8  EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff88010c0b7d78 RCX: 0000000000000c02
RDX: ffff88010c0b7d78 RSI: ffff88011c93dc00 RDI: ffff880103f667b0
RBP: ffff88010c0b7d18 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff880103f667b0
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  00007f479ce7f700(0000) GS:ffff88012a600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000000001c CR3: 000000010529e000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process iknowthis (pid: 27928, threadinfo ffff88010c0b6000, task ffff880103faa4f0)
Stack:
 0000000000000c02 0000000000000c02 ffff88010c0b7d18 ffffff958153cb37
 ffffffff8153cb60 0000000000000c02 ffff88011c93dc00 0000000000000000
 0000000000000c02 ffff88010c0b7e10 ffff88010c0b7de8 ffffffff815372c2
Call Trace:
 [<ffffffff8153cb60>] ? sock_update_classid+0xb0/0x180
 [<ffffffff815372c2>] sock_aio_read.part.10+0x142/0x150
 [<ffffffff812d6752>] ? inode_has_perm+0x62/0xa0
 [<ffffffff815372fd>] sock_aio_read+0x2d/0x40
 [<ffffffff811b05e2>] do_sync_read+0xd2/0x110
 [<ffffffff812d3796>] ? security_file_permission+0x96/0xb0
 [<ffffffff811b0a91>] ? rw_verify_area+0x61/0x100
 [<ffffffff811b103d>] vfs_read+0x16d/0x180
 [<ffffffff811b109d>] sys_read+0x4d/0x90
 [<ffffffff81657282>] system_call_fastpath+0x16/0x1b
Code: 8b 66 20 4c 8b 32 48 89 d3 48 89 4d b8 45 89 c7 c7 45 cc 95 ff ff ff 4d 85 e4 0f 84 ed 01 00 00 49 8b 84 24 18 05 00 00 4c 89 e7 
 78 1c 01 45 19 ed 31 f6 e8 d5 37 ff e0 41 0f b6 44 24 0e 41

Signed-off-by Dave Jones <[email protected]>

net/x25/af_x25.c +8 -3

index 5f03e4e..3e16c6a 100644
@@ -1261,14 +1261,19 @@ static int x25_recvmsg(struct kiocb *iocb, struct socket *sock,
 	struct x25_sock *x25 = x25_sk(sk);
 	struct sockaddr_x25 *sx25 = (struct sockaddr_x25 *)msg->msg_name;
 	size_t copied;
-	int qbit, header_len = x25->neighbour->extended ?
-		X25_EXT_MIN_LEN : X25_STD_MIN_LEN;
-
+	int qbit, header_len;
 	struct sk_buff *skb;
 	unsigned char *asmptr;
 	int rc = -ENOTCONN;
 
 	lock_sock(sk);
+
+	if (x25->neighbour == NULL)
+		goto out;
+
+	header_len = x25->neighbour->extended ?
+		X25_EXT_MIN_LEN : X25_STD_MIN_LEN;
+
 	/*
 	 * This works for seqpacket too. The receiver has ordered the queue for
 	 * us! We do one quick check first though

Eric Dumazet

Acked-by on v2 1/1

2011-11-02 02:30 UTC #7 lore raw

Quoted 4 lines · Dave Jones

commit cb101ed2 in 3.0 introduced a bug in x25_recvmsg() When passed bogus junk from userspace, x25->neighbour can be NULL, as shown in this oops..

...

Quoted 19 lines

Signed-off-by Dave Jones <[email protected]>

net/x25/af_x25.c +1 -3

index 5f03e4e..3e16c6a 100644
@@ -1261,14 +1261,19 @@ static int x25_recvmsg(struct kiocb *iocb, struct socket *sock,
 	struct x25_sock *x25 = x25_sk(sk);
 	struct sockaddr_x25 *sx25 = (struct sockaddr_x25 *)msg->msg_name;
 	size_t copied;
-	int qbit, header_len = x25->neighbour->extended ?
-		X25_EXT_MIN_LEN : X25_STD_MIN_LEN;
-
+	int qbit, header_len;
 	struct sk_buff *skb;
 	unsigned char *asmptr;
 	int rc = -ENOTCONN;
 
 	lock_sock(sk);

net/x25/af_x25.c static int x25_recvmsg(struct kiocb *iocb, struct socket *sock, · line 1279

Quoted 10 lines

net/x25/af_x25.c +7 -0

+
+	if (x25->neighbour == NULL)
+		goto out;
+
+	header_len = x25->neighbour->extended ?
+		X25_EXT_MIN_LEN : X25_STD_MIN_LEN;
+
 	/*
 	 * This works for seqpacket too. The receiver has ordered the queue for
 	 * us! We do one quick check first though

Acked-by Eric Dumazet <[email protected]>

David Miller

maintainer

2011-11-02 04:50 UTC #8 lore raw

From: Eric Dumazet <[email protected]>
Date: Wed, 02 Nov 2011 03:30:17 +0100

Quoted 7 lines · Dave Jones

Quoted 4 lines
commit cb101ed2 in 3.0 introduced a bug in x25_recvmsg() When passed bogus junk from userspace, x25->neighbour can be NULL, as shown in this oops..
...
Quoted 1 line
Signed-off-by Dave Jones <[email protected]>

...

Quoted 1 line

Acked-by Eric Dumazet <[email protected]>

Applied and queued up for -stable, thanks everyone.