* [PATCH] apparmor: Fix null pointer deref when receiving skb during sock creation
@ 2023-09-02 0:48 Xiao Liang
2023-10-16 3:36 ` John Johansen
0 siblings, 1 reply; 4+ messages in thread
From: Xiao Liang @ 2023-09-02 0:48 UTC (permalink / raw)
To: linux-security-module; +Cc: John Johansen, Matthew Garrett
The panic below is observed when receiving ICMP packets with secmark set
while an ICMP raw socket is being created. SK_CTX(sk)->label is updated
in apparmor_socket_post_create(), but the packet is delivered to the
socket before that, causing the null pointer dereference.
Drop the packet if label context is not set.
BUG: kernel NULL pointer dereference, address: 000000000000004c
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020
RIP: 0010:aa_label_next_confined+0xb/0x40
Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 <8b> 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2
RSP: 0018:ffffa92940003b08 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e
RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002
R10: ffffffffbd820eeb R11: ffffffffbeb7ff00 R12: ffff8b574c642400
R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000
FS: 00007fb092ea7640(0000) GS:ffff8b577bc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000004c CR3: 00000001020f2005 CR4: 00000000007706f0
PKRU: 55555554
Call Trace:
<IRQ>
? __die+0x23/0x70
? page_fault_oops+0x171/0x4e0
? exc_page_fault+0x7f/0x180
? asm_exc_page_fault+0x26/0x30
? aa_label_next_confined+0xb/0x40
apparmor_secmark_check+0xec/0x330
security_sock_rcv_skb+0x35/0x50
sk_filter_trim_cap+0x47/0x250
sock_queue_rcv_skb_reason+0x20/0x60
raw_rcv+0x13c/0x210
raw_local_deliver+0x1f3/0x250
ip_protocol_deliver_rcu+0x4f/0x2f0
ip_local_deliver_finish+0x76/0xa0
__netif_receive_skb_one_core+0x89/0xa0
netif_receive_skb+0x119/0x170
? __netdev_alloc_skb+0x3d/0x140
vmxnet3_rq_rx_complete+0xb23/0x1010 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]
vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]
__napi_poll+0x28/0x1b0
net_rx_action+0x2a4/0x380
__do_softirq+0xd1/0x2c8
__irq_exit_rcu+0xbb/0xf0
common_interrupt+0x86/0xa0
</IRQ>
<TASK>
asm_common_interrupt+0x26/0x40
RIP: 0010:apparmor_socket_post_create+0xb/0x200
Code: 08 48 85 ff 75 a1 eb b1 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 <55> 48 89 fd 53 45 85 c0 0f 84 b2 00 00 00 48 8b 1d 80 56 3f 02 48
RSP: 0018:ffffa92940ce7e50 EFLAGS: 00000286
RAX: ffffffffbc756440 RBX: 0000000000000000 RCX: 0000000000000001
RDX: 0000000000000003 RSI: 0000000000000002 RDI: ffff8b574eaab740
RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
R10: ffff8b57444cec70 R11: 0000000000000000 R12: 0000000000000003
R13: 0000000000000002 R14: ffff8b574eaab740 R15: ffffffffbd8e4748
? __pfx_apparmor_socket_post_create+0x10/0x10
security_socket_post_create+0x4b/0x80
__sock_create+0x176/0x1f0
__sys_socket+0x89/0x100
__x64_sys_socket+0x17/0x20
do_syscall_64+0x5d/0x90
? do_syscall_64+0x6c/0x90
? do_syscall_64+0x6c/0x90
? do_syscall_64+0x6c/0x90
entry_SYSCALL_64_after_hwframe+0x72/0xdc
Fixes: ab9f2115081a ("apparmor: Allow filtering based on secmark policy")
Signed-off-by: Xiao Liang <shaw.leon@gmail.com>
---
security/apparmor/lsm.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 108eccc5ada5..0dbff677ac2e 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -1097,6 +1097,13 @@ static int apparmor_socket_sock_rcv_skb(struct sock *sk, struct sk_buff *skb)
if (!skb->secmark)
return 0;
+ /*
+ * If reach here before socket_post_create hook is called, in which
+ * case label is null, drop the packet.
+ */
+ if (!ctx->label)
+ return -EACCES;
+
return apparmor_secmark_check(ctx->label, OP_RECVMSG, AA_MAY_RECEIVE,
skb->secmark, sk);
}
--
2.42.0
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH] apparmor: Fix null pointer deref when receiving skb during sock creation
2023-09-02 0:48 [PATCH] apparmor: Fix null pointer deref when receiving skb during sock creation Xiao Liang
@ 2023-10-16 3:36 ` John Johansen
2024-01-23 6:16 ` Xiao Liang
0 siblings, 1 reply; 4+ messages in thread
From: John Johansen @ 2023-10-16 3:36 UTC (permalink / raw)
To: Xiao Liang, linux-security-module; +Cc: Matthew Garrett
On 9/1/23 17:48, Xiao Liang wrote:
> The panic below is observed when receiving ICMP packets with secmark set
> while an ICMP raw socket is being created. SK_CTX(sk)->label is updated
> in apparmor_socket_post_create(), but the packet is delivered to the
> socket before that, causing the null pointer dereference.
> Drop the packet if label context is not set.
>
> BUG: kernel NULL pointer dereference, address: 000000000000004c
> #PF: supervisor read access in kernel mode
> #PF: error_code(0x0000) - not-present page
> PGD 0 P4D 0
> Oops: 0000 [#1] PREEMPT SMP NOPTI
> CPU: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df
> Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020
> RIP: 0010:aa_label_next_confined+0xb/0x40
> Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 <8b> 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2
> RSP: 0018:ffffa92940003b08 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e
> RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000
> RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002
> R10: ffffffffbd820eeb R11: ffffffffbeb7ff00 R12: ffff8b574c642400
> R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000
> FS: 00007fb092ea7640(0000) GS:ffff8b577bc00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000000000000004c CR3: 00000001020f2005 CR4: 00000000007706f0
> PKRU: 55555554
> Call Trace:
> <IRQ>
> ? __die+0x23/0x70
> ? page_fault_oops+0x171/0x4e0
> ? exc_page_fault+0x7f/0x180
> ? asm_exc_page_fault+0x26/0x30
> ? aa_label_next_confined+0xb/0x40
> apparmor_secmark_check+0xec/0x330
> security_sock_rcv_skb+0x35/0x50
> sk_filter_trim_cap+0x47/0x250
> sock_queue_rcv_skb_reason+0x20/0x60
> raw_rcv+0x13c/0x210
> raw_local_deliver+0x1f3/0x250
> ip_protocol_deliver_rcu+0x4f/0x2f0
> ip_local_deliver_finish+0x76/0xa0
> __netif_receive_skb_one_core+0x89/0xa0
> netif_receive_skb+0x119/0x170
> ? __netdev_alloc_skb+0x3d/0x140
> vmxnet3_rq_rx_complete+0xb23/0x1010 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]
> vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]
> __napi_poll+0x28/0x1b0
> net_rx_action+0x2a4/0x380
> __do_softirq+0xd1/0x2c8
> __irq_exit_rcu+0xbb/0xf0
> common_interrupt+0x86/0xa0
> </IRQ>
> <TASK>
> asm_common_interrupt+0x26/0x40
> RIP: 0010:apparmor_socket_post_create+0xb/0x200
> Code: 08 48 85 ff 75 a1 eb b1 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 <55> 48 89 fd 53 45 85 c0 0f 84 b2 00 00 00 48 8b 1d 80 56 3f 02 48
> RSP: 0018:ffffa92940ce7e50 EFLAGS: 00000286
> RAX: ffffffffbc756440 RBX: 0000000000000000 RCX: 0000000000000001
> RDX: 0000000000000003 RSI: 0000000000000002 RDI: ffff8b574eaab740
> RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
> R10: ffff8b57444cec70 R11: 0000000000000000 R12: 0000000000000003
> R13: 0000000000000002 R14: ffff8b574eaab740 R15: ffffffffbd8e4748
> ? __pfx_apparmor_socket_post_create+0x10/0x10
> security_socket_post_create+0x4b/0x80
> __sock_create+0x176/0x1f0
> __sys_socket+0x89/0x100
> __x64_sys_socket+0x17/0x20
> do_syscall_64+0x5d/0x90
> ? do_syscall_64+0x6c/0x90
> ? do_syscall_64+0x6c/0x90
> ? do_syscall_64+0x6c/0x90
> entry_SYSCALL_64_after_hwframe+0x72/0xdc
>
> Fixes: ab9f2115081a ("apparmor: Allow filtering based on secmark policy")
> Signed-off-by: Xiao Liang <shaw.leon@gmail.com>
not sure how I dropped this one, thanks for the patch. I have pulled it into the apparmor tree
Acked-by: John Johansen <john.johansen@canonical.com>
> ---
> security/apparmor/lsm.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
> index 108eccc5ada5..0dbff677ac2e 100644
> --- a/security/apparmor/lsm.c
> +++ b/security/apparmor/lsm.c
> @@ -1097,6 +1097,13 @@ static int apparmor_socket_sock_rcv_skb(struct sock *sk, struct sk_buff *skb)
> if (!skb->secmark)
> return 0;
>
> + /*
> + * If reach here before socket_post_create hook is called, in which
> + * case label is null, drop the packet.
> + */
> + if (!ctx->label)
> + return -EACCES;
> +
> return apparmor_secmark_check(ctx->label, OP_RECVMSG, AA_MAY_RECEIVE,
> skb->secmark, sk);
> }
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] apparmor: Fix null pointer deref when receiving skb during sock creation
2023-10-16 3:36 ` John Johansen
@ 2024-01-23 6:16 ` Xiao Liang
2024-01-27 8:20 ` John Johansen
0 siblings, 1 reply; 4+ messages in thread
From: Xiao Liang @ 2024-01-23 6:16 UTC (permalink / raw)
To: John Johansen; +Cc: linux-security-module, Matthew Garrett
On Mon, Oct 16, 2023 at 11:36 AM John Johansen
<john.johansen@canonical.com> wrote:
>
> On 9/1/23 17:48, Xiao Liang wrote:
> > The panic below is observed when receiving ICMP packets with secmark set
> > while an ICMP raw socket is being created. SK_CTX(sk)->label is updated
> > in apparmor_socket_post_create(), but the packet is delivered to the
> > socket before that, causing the null pointer dereference.
> > Drop the packet if label context is not set.
>
> not sure how I dropped this one, thanks for the patch. I have pulled it into the apparmor tree
>
I haven't seen this patch in the tree yet. May I know the status?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] apparmor: Fix null pointer deref when receiving skb during sock creation
2024-01-23 6:16 ` Xiao Liang
@ 2024-01-27 8:20 ` John Johansen
0 siblings, 0 replies; 4+ messages in thread
From: John Johansen @ 2024-01-27 8:20 UTC (permalink / raw)
To: Xiao Liang; +Cc: linux-security-module, Matthew Garrett
On 1/22/24 22:16, Xiao Liang wrote:
> On Mon, Oct 16, 2023 at 11:36 AM John Johansen
> <john.johansen@canonical.com> wrote:
>>
>> On 9/1/23 17:48, Xiao Liang wrote:
>>> The panic below is observed when receiving ICMP packets with secmark set
>>> while an ICMP raw socket is being created. SK_CTX(sk)->label is updated
>>> in apparmor_socket_post_create(), but the packet is delivered to the
>>> socket before that, causing the null pointer dereference.
>>> Drop the packet if label context is not set.
>>
>> not sure how I dropped this one, thanks for the patch. I have pulled it into the apparmor tree
>>
>
> I haven't seen this patch in the tree yet. May I know the status?
sorry, this did get pulled in, but for some reason, didn't get promoted into apparmor-next
I will try to send it up for -rc3
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-01-27 8:20 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-09-02 0:48 [PATCH] apparmor: Fix null pointer deref when receiving skb during sock creation Xiao Liang
2023-10-16 3:36 ` John Johansen
2024-01-23 6:16 ` Xiao Liang
2024-01-27 8:20 ` John Johansen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.