forked from luck/tmp_suning_uos_patched
RxRPC: Allocate tokens with kzalloc to avoid oops in rxrpc_destroy
With slab poisoning enabled, I see the following oops: Unable to handle kernel paging request for data at address 0x6b6b6b6b6b6b6b73 ... NIP [c0000000006bc61c] .rxrpc_destroy+0x44/0x104 LR [c0000000006bc618] .rxrpc_destroy+0x40/0x104 Call Trace: [c0000000feb2bc00] [c0000000006bc618] .rxrpc_destroy+0x40/0x104 (unreliable) [c0000000feb2bc90] [c000000000349b2c] .key_cleanup+0x1a8/0x20c [c0000000feb2bd40] [c0000000000a2920] .process_one_work+0x2f4/0x4d0 [c0000000feb2be00] [c0000000000a2d50] .worker_thread+0x254/0x468 [c0000000feb2bec0] [c0000000000a868c] .kthread+0xbc/0xc8 [c0000000feb2bf90] [c000000000020e00] .kernel_thread+0x54/0x70 We aren't initialising token->next, but the code in destroy_context relies on the list being NULL terminated. Use kzalloc to zero out all the fields. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
parent
f129ccc923
commit
0a93ea2e89
|
@ -89,11 +89,11 @@ static int rxrpc_instantiate_xdr_rxkad(struct key *key, const __be32 *xdr,
|
|||
return ret;
|
||||
|
||||
plen -= sizeof(*token);
|
||||
token = kmalloc(sizeof(*token), GFP_KERNEL);
|
||||
token = kzalloc(sizeof(*token), GFP_KERNEL);
|
||||
if (!token)
|
||||
return -ENOMEM;
|
||||
|
||||
token->kad = kmalloc(plen, GFP_KERNEL);
|
||||
token->kad = kzalloc(plen, GFP_KERNEL);
|
||||
if (!token->kad) {
|
||||
kfree(token);
|
||||
return -ENOMEM;
|
||||
|
@ -731,10 +731,10 @@ static int rxrpc_instantiate(struct key *key, const void *data, size_t datalen)
|
|||
goto error;
|
||||
|
||||
ret = -ENOMEM;
|
||||
token = kmalloc(sizeof(*token), GFP_KERNEL);
|
||||
token = kzalloc(sizeof(*token), GFP_KERNEL);
|
||||
if (!token)
|
||||
goto error;
|
||||
token->kad = kmalloc(plen, GFP_KERNEL);
|
||||
token->kad = kzalloc(plen, GFP_KERNEL);
|
||||
if (!token->kad)
|
||||
goto error_free;
|
||||
|
||||
|
|
Loading…
Reference in New Issue
Block a user