On 2/7/19 10:00 PM, Joe Perches wrote: > On Thu, 2019-02-07 at 18:28 -0600, Gustavo A. R. Silva wrote: >> One of the more common cases of allocation size calculations is finding >> the size of a structure that has a zero-sized array at the end, along >> with memory for some number of elements for that array. For example: >> >> struct foo { >> int stuff; >> struct boo entry[]; >> }; >> >> size = sizeof(struct foo) + count * sizeof(struct boo); >> instance = alloc(size, GFP_KERNEL) >> >> Instead of leaving these open-coded and prone to type mistakes, we can >> now use the new struct_size() helper: >> >> size = struct_size(instance, entry, count); >> instance = alloc(size, GFP_KERNEL) >> >> This code was detected with the help of Coccinelle. > [] >> diff --git a/net/bluetooth/a2mp.c b/net/bluetooth/a2mp.c > [] >> @@ -174,7 +174,7 @@ static int a2mp_discover_req(struct amp_mgr *mgr, struct sk_buff *skb, >> num_ctrl++; >> } >> >> - len = num_ctrl * sizeof(struct a2mp_cl) + sizeof(*rsp); >> + len = struct_size(rsp, cl, num_ctrl); >> rsp = kmalloc(len, GFP_ATOMIC); >> if (!rsp) { >> read_unlock(&hci_dev_list_lock); > > At least a weakness in this code is len is u16 > and struct_size is size_t so there's a size > truncation possible. > > That's true. I didn't change the type to size_t because of the call to le16_to_cpu(): u16 len = le16_to_cpu(hdr->len); I've been changing the type of the variable in other cases. -- Gustavo