On 10/18/2018 10:34 AM, Eric Dumazet wrote:
>
>
> On 10/17/2018 10:20 PM, John Fastabend wrote:
>> Before using the psock returned by sk_psock_get() when adding it to a
>> sockmap we need to ensure it is actually a sockmap based psock.
>> Previously we were only checking this after incrementing the reference
>> counter which was an error. This resulted in a slab-out-of-bounds
>> error when the psock was not actually a sockmap type.
>>
>> This moves the check up so the reference counter is only used
>> if it is a sockmap psock.
>>
>> Eric reported the following KASAN BUG,
>>
>> 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
>>
>> Signed-off-by: John Fastabend <john.fastab...@gmail.com>
>> Reported-by: Eric Dumazet <eric.duma...@gmail.com>
>> Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
>> ---
[...]
>> +static inline struct sk_psock *sk_psock_get_checked(struct sock *sk)
>> +{
>> + struct sk_psock *psock;
>> +
>> + rcu_read_lock();
>> + psock = sk_psock(sk);
>> + if (psock) {
>> + if (sk->sk_prot->recvmsg != tcp_bpf_recvmsg) {
>> + psock = ERR_PTR(-EBUSY);
>> + goto out;
>> + }
>> +
>> + if (!refcount_inc_not_zero(&psock->refcnt))
>> + psock = NULL;
>
> Caller is using IS_ERR(), so you probably want to :
>
> psock = ERR_PTR(-E<something>);
>
>
Yeah we can make this EBUSY as well. Originally I was
thinking that we could create the psock and attach it in
this case but it would be racy and require an rcu sync
most likely.
To hit this case users would need to have multiple
maps and be adding/deleting socks from those maps at
the same time. Seems pretty rare and not worth punishing
the normal case with synchronization.
Nice catch.
.John
