| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <4b403534-2273-5931-753b-c16a6e2624a0@gmail.com>
Date: Wed, 17 Oct 2018 07:55:37 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Daniel Borkmann <daniel@...earbox.net>,
alexei.starovoitov@...il.com
Cc: john.fastabend@...il.com, davejwatson@...com,
netdev@...r.kernel.org
Subject: Re: [PATCH bpf-next v2 4/8] tls: convert to generic sk_msg interface
On 10/12/2018 05:45 PM, Daniel Borkmann wrote:
> Convert kTLS over to make use of sk_msg interface for plaintext and
> encrypted scattergather data, so it reuses all the sk_msg helpers
> and data structure which later on in a second step enables to glue
> this to BPF.
>
> This also allows to remove quite a bit of open coded helpers which
> are covered by the sk_msg API. Recent changes in kTLs 80ece6a03aaf
> ("tls: Remove redundant vars from tls record structure") and
> 4e6d47206c32 ("tls: Add support for inplace records encryption")
> changed the data path handling a bit; while we've kept the latter
> optimization intact, we had to undo the former change to better
> fit the sk_msg model, hence the sg_aead_in and sg_aead_out have
> been brought back and are linked into the sk_msg sgs. Now the kTLS
> record contains a msg_plaintext and msg_encrypted sk_msg each.
>
> In the original code, the zerocopy_from_iter() has been used out
> of TX but also RX path. For the strparser skb-based RX path,
> we've left the zerocopy_from_iter() in decrypt_internal() mostly
> untouched, meaning it has been moved into tls_setup_from_iter()
> with charging logic removed (as not used from RX). Given RX path
> is not based on sk_msg objects, we haven't pursued setting up a
> dummy sk_msg to call into sk_msg_zerocopy_from_iter(), but it
> could be an option to prusue in a later step.
>
> Joint work with John.
>
>
Something looks broken and needs this fix :
(I have to run, I might submit this formally later if needed)
diff --git a/net/core/sock_map.c b/net/core/sock_map.c
index 3c0e44cb811a4bed2e02aa107854d74eb3ae7358..3e55dedc038b22132b5b6d042bfedda9e4f3157e 100644
--- a/net/core/sock_map.c
+++ b/net/core/sock_map.c
@@ -175,12 +175,12 @@ static int sock_map_link(struct bpf_map *map, struct sk_psock_progs *progs,
}
}
+ if (!sk_has_psock(sk)) {
+ ret = -EBUSY;
+ goto out_progs;
+ }
psock = sk_psock_get(sk);
if (psock) {
- if (!sk_has_psock(sk)) {
- ret = -EBUSY;
- goto out_progs;
- }
if ((msg_parser && READ_ONCE(psock->progs.msg_parser)) ||
(skb_progs && READ_ONCE(psock->progs.skb_parser))) {
sk_psock_put(sk, psock);
BUG: KASAN: slab-out-of-bounds in atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
BUG: KASAN: slab-out-of-bounds in refcount_inc_not_zero_checked+0x97/0x2f0 lib/refcount.c:120
Read of size 4 at addr ffff88019548be58 by task syz-executor4/22387
CPU: 1 PID: 22387 Comm: syz-executor4 Not tainted 4.19.0-rc7+ #264
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
check_memory_region_inline mm/kasan/kasan.c:260 [inline]
check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
kasan_check_read+0x11/0x20 mm/kasan/kasan.c:272
atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
refcount_inc_not_zero_checked+0x97/0x2f0 lib/refcount.c:120
sk_psock_get include/linux/skmsg.h:379 [inline]
sock_map_link.isra.6+0x41f/0xe30 net/core/sock_map.c:178
sock_hash_update_common+0x19b/0x11e0 net/core/sock_map.c:669
sock_hash_update_elem+0x306/0x470 net/core/sock_map.c:738
map_update_elem+0x819/0xdf0 kernel/bpf/syscall.c:818
__do_sys_bpf kernel/bpf/syscall.c:2400 [inline]
__se_sys_bpf kernel/bpf/syscall.c:2371 [inline]
__x64_sys_bpf+0x32d/0x510 kernel/bpf/syscall.c:2371
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457569
Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f71507e0c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457569
RDX: 0000000000000020 RSI: 0000000020000180 RDI: 0000000000000002
RBP: 000000000072bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f71507e16d4
R13: 00000000004bd926 R14: 00000000004cc2b0 R15: 00000000ffffffff
Allocated by task 22387:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
kmem_cache_alloc+0x12e/0x730 mm/slab.c:3554
kmem_cache_zalloc include/linux/slab.h:697 [inline]
kcm_attach net/kcm/kcmsock.c:1405 [inline]
kcm_attach_ioctl net/kcm/kcmsock.c:1490 [inline]
kcm_ioctl+0xca7/0x18c0 net/kcm/kcmsock.c:1696
sock_do_ioctl+0xeb/0x420 net/socket.c:950
sock_ioctl+0x313/0x690 net/socket.c:1074
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:501 [inline]
do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685
ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702
__do_sys_ioctl fs/ioctl.c:709 [inline]
__se_sys_ioctl fs/ioctl.c:707 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 0:
(stack is not available)
The buggy address belongs to the object at ffff88019548bc00
which belongs to the cache kcm_psock_cache of size 544
The buggy address is located 56 bytes to the right of
544-byte region [ffff88019548bc00, ffff88019548be20)
The buggy address belongs to the page:
page:ffffea0006552280 count:1 mapcount:0 mapping:ffff8801cb789b40 index:0x0 compound_mapcount: 0
flags: 0x2fffc0000008100(slab|head)
raw: 02fffc0000008100 ffff8801cb78c748 ffff8801cb78c748 ffff8801cb789b40
kobject: 'loop2' (0000000086df2c8c): kobject_uevent_env
raw: 0000000000000000 ffff88019548a080 000000010000000b 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88019548bd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88019548bd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff88019548be00: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff88019548be80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88019548bf00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
Powered by blists - more mailing lists