Re: [PATCH] 9p: Transport error uninitialized
From: Shuaibing Lu
Date: Mon Jun 17 2019 - 03:33:12 EST
å 2019/6/13 äå7:10, Dominique Martinet åé:
> Lu Shuaibing wrote on Thu, Jun 13, 2019:
>> The p9_tag_alloc() does not initialize the transport error t_err field.
>> The struct p9_req_t *req is allocated and stored in a struct p9_client
>> variable. The field t_err is never initialized before p9_conn_cancel()
>> checks its value.
>> KUMSAN(KernelUninitializedMemorySantizer, a new error detection tool)
>> reports this bug.
>> BUG: KUMSAN: use of uninitialized memory in p9_conn_cancel+0x2d9/0x3b0
>> Read of size 4 at addr ffff88805f9b600c by task kworker/1:2/1216
>> CPU: 1 PID: 1216 Comm: kworker/1:2 Not tainted 5.2.0-rc4+ #28
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
>> Workqueue: events p9_write_work
>> Call Trace:
>> Allocated by task 1979:
>> Freed by task 0:
>> (stack is not available)
>> The buggy address belongs to the object at ffff88805f9b6008
>> which belongs to the cache p9_req_t of size 144
>> The buggy address is located 4 bytes inside of
>> 144-byte region [ffff88805f9b6008, ffff88805f9b6098)
>> The buggy address belongs to the page:
>> page:ffffea00017e6d80 refcount:1 mapcount:0 mapping:ffff888068b63740 index:0xffff88805f9b7d90 compound_mapcount: 0
>> flags: 0x100000000010200(slab|head)
>> raw: 0100000000010200 ffff888068b66450 ffff888068b66450 ffff888068b63740
>> raw: ffff88805f9b7d90 0000000000100001 00000001ffffffff 0000000000000000
>> page dumped because: kumsan: bad access detected
>> Signed-off-by: Lu Shuaibing <shuaibinglu@xxxxxxx>
> Looks good to me, will queue it up for -next after I've had time to run
> some tests - probably early next week.
> This made me realize that this refcount_set is too late, it is possible
> in theory to find the request with p9_tag_lookup as soon as the tag
> alloc worked so both this req->t_err and refcount initialization should
> go before the idr chunk with the other field initializations.
> I also checked by the way that no other fields were forgotten, the only
> field that is not initialized now is ->aux, but that field is never used
> so it might be just as fast to remove the field instead...
> I'll submit a couple of patches to move these two inits up and remove
> the aux field when I find time.
Thanks for your reply. The kumsan tool finds only one field is used
initialized. The ->aux field could