Bug 2298145 (CVE-2022-48809) - CVE-2022-48809 kernel: net: fix a memleak when uncloning an skb dst and its metadata
Summary: CVE-2022-48809 kernel: net: fix a memleak when uncloning an skb dst and its m...
Keywords:
Status: NEW
Alias: CVE-2022-48809
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-07-16 12:30 UTC by OSIDB Bzimport
Modified: 2024-07-30 17:45 UTC (History)
4 users (show)

Fixed In Version: kernel 4.9.302, kernel 4.14.267, kernel 4.19.230, kernel 5.4.180, kernel 5.10.101, kernel 5.15.24, kernel 5.16.10, kernel 5.17
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2024-07-16 12:30:11 UTC
In the Linux kernel, the following vulnerability has been resolved:

net: fix a memleak when uncloning an skb dst and its metadata

When uncloning an skb dst and its associated metadata, a new
dst+metadata is allocated and later replaces the old one in the skb.
This is helpful to have a non-shared dst+metadata attached to a specific
skb.

The issue is the uncloned dst+metadata is initialized with a refcount of
1, which is increased to 2 before attaching it to the skb. When
tun_dst_unclone returns, the dst+metadata is only referenced from a
single place (the skb) while its refcount is 2. Its refcount will never
drop to 0 (when the skb is consumed), leading to a memory leak.

Fix this by removing the call to dst_hold in tun_dst_unclone, as the
dst+metadata refcount is already 1.


Note You need to log in before you can comment on or make changes to this bug.