https://vulnerability.circl.lu/sightings/feed 2026-05-10T05:03:26.319041+00:00 Vulnerability-Lookup info@circl.lu python-feedgen Contains only the most 10 recent sightings. https://vulnerability.circl.lu/sighting/4d586c60-29a2-4f70-ad43-14e5a0c6cd35/export 2026-05-10T05:03:26.706269+00:00 Automation user http://cve.circl.lu/user/automation {"uuid": "4d586c60-29a2-4f70-ad43-14e5a0c6cd35", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-48809", "type": "seen", "source": "https://t.me/cvedetector/946", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2022-48809 - Linux Net SKB Destination Metadata Leak\", \n \"Content\": \"CVE ID : CVE-2022-48809 \nPublished : July 16, 2024, 12:15 p.m. | 43\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nnet: fix a memleak when uncloning an skb dst and its metadata \n \nWhen uncloning an skb dst and its associated metadata, a new \ndst+metadata is allocated and later replaces the old one in the skb. \nThis is helpful to have a non-shared dst+metadata attached to a specific \nskb. \n \nThe issue is the uncloned dst+metadata is initialized with a refcount of \n1, which is increased to 2 before attaching it to the skb. When \ntun_dst_unclone returns, the dst+metadata is only referenced from a \nsingle place (the skb) while its refcount is 2. Its refcount will never \ndrop to 0 (when the skb is consumed), leading to a memory leak. \n \nFix this by removing the call to dst_hold in tun_dst_unclone, as the \ndst+metadata refcount is already 1. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"16 Jul 2024\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-16T15:26:35.000000Z"} 2024-07-16T15:26:35+00:00