summaryrefslogtreecommitdiff
path: root/net/ieee802154/6lowpan
diff options
context:
space:
mode:
authorKieran Bingham <kieranbingham@gmail.com>2015-09-02 15:51:10 +0300
committerMarcel Holtmann <marcel@holtmann.org>2015-09-17 14:20:02 +0300
commit517a5460a93d641e2beb362d4066f9861f108e2f (patch)
tree213b888f26c59ea5b46c2533a796edf69a90b0f5 /net/ieee802154/6lowpan
parent6b3cc1db68ac83647d37f7d16f0261621eda24aa (diff)
downloadlinux-517a5460a93d641e2beb362d4066f9861f108e2f.tar.xz
Bluetooth: btmrvl: skb resource leak, and double free.
if btmrvl_tx_pkt() is called, and the branch if (skb_headroom(skb) < BTM_HEADER_LEN) evaluates positive, a new skb is allocated via skb_realloc_headroom. The original skb is stored in a tmp variable, before being free'd. However on success, the new skb, is not free'd, nor is it returned to the caller which will then double-free the original skb. This issue exists from the original driver submission in commit: #132ff4e5fa8dfb71a7d99902f88043113947e972 If this code path had been alive, it would have been noted from the double-free causing a panic. All skb's here should be allocated through bt_skb_alloc which adds 8 bytes as headroom, which is plenty against the 4 bytes pushed on by this driver. This code path is dead, and buggy at the same time, so the cleanest approach is to remove the affected branch. Reported by coverity (CID 113422) Signed-off-by: Kieran Bingham <kieranbingham@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Diffstat (limited to 'net/ieee802154/6lowpan')
0 files changed, 0 insertions, 0 deletions