deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-48791
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: pm8001: Fix use-after-free for aborted TMF sas_task

Currently a use-after-free may occur if a TMF sas_task is aborted before we
handle the IO completion in mpi_ssp_completion(). The abort occurs due to
timeout.

When the timeout occurs, the SAS_TASK_STATE_ABORTED flag is set and the
sas_task is freed in pm8001_exec_internal_tmf_task().

However, if the I/O completion occurs later, the I/O completion still
thinks that the sas_task is available. Fix this by clearing the ccb->task
if the TMF times out - the I/O completion handler does nothing if this
pointer is cleared.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/3c334cdfd94945b8edb94022a0371a8665b17366; https://git.kernel.org/stable/c/510b21442c3a2e3ecc071ba3e666b320e7acdd61; https://git.kernel.org/stable/c/61f162aa4381845acbdc7f2be4dfb694d027c018
CVE: CVE-2022-48792
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: pm8001: Fix use-after-free for aborted SSP/STP sas_task

Currently a use-after-free may occur if a sas_task is aborted by the upper
layer before we handle the I/O completion in mpi_ssp_completion() or
mpi_sata_completion().

In this case, the following are the two steps in handling those I/O
completions:

 - Call complete() to inform the upper layer handler of completion of
   the I/O.

 - Release driver resources associated with the sas_task in
   pm8001_ccb_task_free() call.

When complete() is called, the upper layer may free the sas_task. As such,
we should not touch the associated sas_task afterwards, but we do so in the
pm8001_ccb_task_free() call.

Fix by swapping the complete() and pm8001_ccb_task_free() calls ordering.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/d9d93f32534a0a80a1c26bdb0746d90a7b19c2c2; https://git.kernel.org/stable/c/df7abcaa1246e2537ab4016077b5443bb3c09378; https://git.kernel.org/stable/c/f61f9fccb2cb4bb275674a79d638704db6bc2171
CVE: CVE-2022-48793
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: nSVM: fix potential NULL derefernce on nested migration

Turns out that due to review feedback and/or rebases
I accidentally moved the call to nested_svm_load_cr3 to be too early,
before the NPT is enabled, which is very wrong to do.

KVM can't even access guest memory at that point as nested NPT
is needed for that, and of course it won't initialize the walk_mmu,
which is main issue the patch was addressing.

Fix this for real.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/352193edda48e08e8824a7ece09aec830a603cfe; https://git.kernel.org/stable/c/74b426bea4f7e3b081add2b88d4fba16d3af7ab6; https://git.kernel.org/stable/c/e1779c2714c3023e[PII_REDACTED]bcbc43a3b943df
CVE: CVE-2022-48794
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ieee802154: at86rf230: Stop leaking skb's

Upon error the ieee802154_xmit_complete() helper is not called. Only
ieee802154_wake_queue() is called manually. In the Tx case we then leak
the skb structure.

Free the skb structure upon error before returning when appropriate.

As the 'is_tx = 0' cannot be moved in the complete handler because of a
possible race between the delay in switching to STATE_RX_AACK_ON and a
new interrupt, we introduce an intermediate 'was_tx' boolean just for
this purpose.

There is no Fixes tag applying here, many changes have been made on this
area and the issue kind of always existed.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/0fd484644c68897c490a3307bfcc8bf767df5a43; https://git.kernel.org/stable/c/1c72f04d52b7200bb83426a9bed378668271ea4a; https://git.kernel.org/stable/c/23b2a[PII_REDACTED]8427ea278f3d8bf4ecfd333bf
CVE: CVE-2022-48797
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

mm: don't try to NUMA-migrate COW pages that have other uses

Oded Gabbay reports that enabling NUMA balancing causes corruption with
his Gaudi accelerator test load:

 "All the details are in the bug, but the bottom line is that somehow,
  this patch causes corruption when the numa balancing feature is
  enabled AND we don't use process affinity AND we use GUP to pin pages
  so our accelerator can DMA to/from system memory.

  Either disabling numa balancing, using process affinity to bind to
  specific numa-node or reverting this patch causes the bug to
  disappear"

and Oded bisected the issue to commit 09854ba94c6a ("mm: do_wp_page()
simplification").

Now, the NUMA balancing shouldn't actually be changing the writability
of a page, and as such shouldn't matter for COW.  But it appears it
does.  Suspicious.

However, regardless of that, the condition for enabling NUMA faults in
change_pte_range() is nonsensical.  It uses "page_mapcount(page)" to
decide if a COW page should be NUMA-protected or not, and that makes
absolutely no sense.

The number of mappings a page has is irrelevant: not only does GUP get a
reference to a page as in Oded's case, but the other mappings migth be
paged out and the only reference to them would be in the page count.

Since we should never try to NUMA-balance a page that we can't move
anyway due to other references, just fix the code to use 'page_count()'.
Oded confirms that that fixes his issue.

Now, this does imply that something in NUMA balancing ends up changing
page protections (other than the obvious one of making the page
inaccessible to get the NUMA faulting information).  Otherwise the COW
simplification wouldn't matter - since doing the GUP on the page would
make sure it's writable.

The cause of that permission change would be good to figure out too,
since it clearly results in spurious COW events - but fixing the
nonsensical test that just happened to work before is obviously the
CorrectThing(tm) to do regardless.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/254090925e16abd914c87b4ad1b489440d89c4c3; https://git.kernel.org/stable/c/80d47f5de5e311cbc0d01ebb6ee684e8f4c196c6; https://git.kernel.org/stable/c/b3dc4b9d3ca68b370c4aeab5355007eedf948849
CVE: CVE-2022-48798
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

s390/cio: verify the driver availability for path_event call

If no driver is attached to a device or the driver does not provide the
path_event function, an FCES path-event on this device could end up in a
kernel-panic. Verify the driver availability before the path_event
function call.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/a0619027f11590b[PII_REDACTED]530c34dc7f91bcd; https://git.kernel.org/stable/c/dd9cb842fa9d90653a9b48aba52f89c069f3bc50; https://git.kernel.org/stable/c/fe990b7bf6ac93f1d850d076b8f0e758268aa4ab
CVE: CVE-2022-48799
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

perf: Fix list corruption in perf_cgroup_switch()

There's list corruption on cgrp_cpuctx_list. This happens on the
following path:

  perf_cgroup_switch: list_for_each_entry(cgrp_cpuctx_list)
      cpu_ctx_sched_in
         ctx_sched_in
            ctx_pinned_sched_in
              merge_sched_in
                  perf_cgroup_event_disable: remove the event from the list

Use list_for_each_entry_safe() to allow removing an entry during
iteration.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2142bc1469a316fddd10012d76428f7265258f81; https://git.kernel.org/stable/c/30d9f3cbe47e1018ddc8069ac5b5c9e66fbdf727; https://git.kernel.org/stable/c/5d76ed4223403f90421782adb2f20a9ecbc93186
CVE: CVE-2022-48800
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

mm: vmscan: remove deadlock due to throttling failing to make progress

A soft lockup bug in kcompactd was reported in a private bugzilla with
the following visible in dmesg;

  watchdog: BUG: soft lockup - CPU#33 stuck for 26s! [kcompactd0:479]
  watchdog: BUG: soft lockup - CPU#33 stuck for 52s! [kcompactd0:479]
  watchdog: BUG: soft lockup - CPU#33 stuck for 78s! [kcompactd0:479]
  watchdog: BUG: soft lockup - CPU#33 stuck for 104s! [kcompactd0:479]

The machine had 256G of RAM with no swap and an earlier failed
allocation indicated that node 0 where kcompactd was run was potentially
unreclaimable;

  Node 0 active_anon:29355112kB inactive_anon:2913528kB active_file:0kB
    inactive_file:0kB unevictable:64kB isolated(anon):0kB isolated(file):0kB
    mapped:8kB dirty:0kB writeback:0kB shmem:26780kB shmem_thp:
    0kB shmem_pmdmapped: 0kB anon_thp: 23480320kB writeback_tmp:0kB
    kernel_stack:2272kB pagetables:24500kB all_unreclaimable? yes

Vlastimil Babka investigated a crash dump and found that a task
migrating pages was trying to drain PCP lists;

  PID: 52922  TASK: ffff969f820e5000  CPU: 19  COMMAND: "kworker/u128:3"
  Call Trace:
     __schedule
     schedule
     schedule_timeout
     wait_for_completion
     __flush_work
     __drain_all_pages
     __alloc_pages_slowpath.constprop.114
     __alloc_pages
     alloc_migration_target
     migrate_pages
     migrate_to_node
     do_migrate_pages
     cpuset_migrate_mm_workfn
     process_one_work
     worker_thread
     kthread
     ret_from_fork

This failure is specific to CONFIG_PREEMPT=n builds.  The root of the
problem is that kcompact0 is not rescheduling on a CPU while a task that
has isolated a large number of the pages from the LRU is waiting on
kcompact0 to reschedule so the pages can be released.  While
shrink_inactive_list() only loops once around too_many_isolated, reclaim
can continue without rescheduling if sc->skipped_deactivate == 1 which
could happen if there was no file LRU and the inactive anon list was not
low.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/3980cff6349687f73d5109f156f23cb261c24164; https://git.kernel.org/stable/c/b485c6f1f9f54b81443efda5f3d8a5036ba2cd91; https://git.kernel.org/stable/c/3980cff6349687f73d5109f156f23cb261c24164
CVE: CVE-2022-48801
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: buffer: Fix file related error handling in IIO_BUFFER_GET_FD_IOCTL

If we fail to copy the just created file descriptor to userland, we
try to clean up by putting back 'fd' and freeing 'ib'. The code uses
put_unused_fd() for the former which is wrong, as the file descriptor
was already published by fd_install() which gets called internally by
anon_inode_getfd().

This makes the error handling code leaving a half cleaned up file
descriptor table around and a partially destructed 'file' object,
allowing userland to play use-after-free tricks on us, by abusing
the still usable fd and making the code operate on a dangling
'file->private_data' pointer.

Instead of leaving the kernel in a partially corrupted state, don't
attempt to explicitly clean up and leave this to the process exit
path that'll release any still valid fds, including the one created
by the previous call to anon_inode_getfd(). Simply return -EFAULT to
indicate the error.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/202071d[PII_REDACTED]d291aa7cf26af54e674f4d4; https://git.kernel.org/stable/c/b7f54894aa7517d2b6c797a499b9f491e9db9083; https://git.kernel.org/stable/c/c72ea20503610a4a7ba26c769357d31602769c01
CVE: CVE-2022-48803
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

phy: ti: Fix missing sentinel for clk_div_table

_get_table_maxdiv() tries to access "clk_div_table" array out of bound
defined in phy-j721e-wiz.c. Add a sentinel entry to prevent
the following global-out-of-bounds error reported by enabling KASAN.

[    9.552392] BUG: KASAN: global-out-of-bounds in _get_maxdiv+0xc0/0x148
[    9.558948] Read of size 4 at addr ffff8000095b25a4 by task kworker/u4:1/38
[    9.565926]
[    9.567441] CPU: 1 PID: 38 Comm: kworker/u4:1 Not tainted 5.16.0-116492-gdaadb3bd0e8d-dirty #360
[    9.576242] Hardware name: Texas Instruments J721e EVM (DT)
[    9.581832] Workqueue: events_unbound deferred_probe_work_func
[    9.587708] Call trace:
[    9.590174]  dump_backtrace+0x20c/0x218
[    9.594038]  show_stack+0x18/0x68
[    9.597375]  dump_stack_lvl+0x9c/0xd8
[    9.601062]  print_address_description.constprop.0+0x78/0x334
[    9.606830]  kasan_report+0x1f0/0x260
[    9.610517]  __asan_load4+0x9c/0xd8
[    9.614030]  _get_maxdiv+0xc0/0x148
[    9.617540]  divider_determine_rate+0x88/0x488
[    9.622005]  divider_round_rate_parent+0xc8/0x124
[    9.626729]  wiz_clk_div_round_rate+0x54/0x68
[    9.631113]  clk_core_determine_round_nolock+0x124/0x158
[    9.636448]  clk_core_round_rate_nolock+0x68/0x138
[    9.641260]  clk_core_set_rate_nolock+0x268/0x3a8
[    9.645987]  clk_set_rate+0x50/0xa8
[    9.649499]  cdns_sierra_phy_init+0x88/0x248
[    9.653794]  phy_init+0x98/0x108
[    9.657046]  cdns_pcie_enable_phy+0xa0/0x170
[    9.661340]  cdns_pcie_init_phy+0x250/0x2b0
[    9.665546]  j721e_pcie_probe+0x4b8/0x798
[    9.669579]  platform_probe+0x8c/0x108
[    9.673350]  really_probe+0x114/0x630
[    9.677037]  __driver_probe_device+0x18c/0x220
[    9.681505]  driver_probe_device+0xac/0x150
[    9.685712]  __device_attach_driver+0xec/0x170
[    9.690178]  bus_for_each_drv+0xf0/0x158
[    9.694124]  __device_attach+0x184/0x210
[    9.698070]  device_initial_probe+0x14/0x20
[    9.702277]  bus_probe_device+0xec/0x100
[    9.706223]  deferred_probe_work_func+0x124/0x180
[    9.710951]  process_one_work+0x4b0/0xbc0
[    9.714983]  worker_thread+0x74/0x5d0
[    9.718668]  kthread+0x214/0x230
[    9.721919]  ret_from_fork+0x10/0x20
[    9.725520]
[    9.727032] The buggy address belongs to the variable:
[    9.732183]  clk_div_table+0x24/0x440
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-125
References: https://git.kernel.org/stable/c/3c75d1017cb362b6a4e0935746ef5da28250919f; https://git.kernel.org/stable/c/5b0c9569135a37348c1267c81e8b0274b21a86ed; https://git.kernel.org/stable/c/6d1e6bcb31663ee83aaea1f171f3dbfe95dd4a69
CVE: CVE-2022-48804
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

vt_ioctl: fix array_index_nospec in vt_setactivate

array_index_nospec ensures that an out-of-bounds value is set to zero
on the transient path. Decreasing the value by one afterwards causes
a transient integer underflow. vsa.console should be decreased first
and then sanitized with array_index_nospec.

Kasper Acknowledgements: Jakob Koschel, Brian Johannesmeyer, Kaveh
Razavi, Herbert Bos, Cristiano Giuffrida from the VUSec group at VU
Amsterdam.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-191
References: https://git.kernel.org/stable/c/170325aba4608bde3e7d21c9c19b7bc266ac0885; https://git.kernel.org/stable/c/2a45a6bd1e6d651770aafff57ab3e1d3bb0b42e0; https://git.kernel.org/stable/c/61cc70d9e8ef5b042d4ed87994d20100ec8896d9
CVE: CVE-2022-48805
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: usb: ax88179_178a: Fix out-of-bounds accesses in RX fixup

ax88179_rx_fixup() contains several out-of-bounds accesses that can be
triggered by a malicious (or defective) USB device, in particular:

 - The metadata array (hdr_off..hdr_off+2*pkt_cnt) can be out of bounds,
   causing OOB reads and (on big-endian systems) OOB endianness flips.
 - A packet can overlap the metadata array, causing a later OOB
   endianness flip to corrupt data used by a cloned SKB that has already
   been handed off into the network stack.
 - A packet SKB can be constructed whose tail is far beyond its end,
   causing out-of-bounds heap data to be considered part of the SKB's
   data.

I have tested that this can be used by a malicious USB device to send a
bogus ICMPv6 Echo Request and receive an ICMPv6 Echo Reply in response
that contains random kernel heap data.
It's probably also possible to get OOB writes from this on a
little-endian system somehow - maybe by triggering skb_cow() via IP
options processing -, but I haven't tested that.
CVSS Score: 7.8 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/1668781ed24da43498799aa4f65714a7de201930; https://git.kernel.org/stable/c/57bc3d3ae8c14df3ceb4e17d26ddf9eeab304581; https://git.kernel.org/stable/c/63f0cfb36c1f1964a59ce[PII_REDACTED]01e2d8740
CVE: CVE-2022-48806
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

eeprom: ee1004: limit i2c reads to I2C_SMBUS_BLOCK_MAX

Commit effa453168a7 ("i2c: i801: Don't silently correct invalid transfer
size") revealed that ee1004_eeprom_read() did not properly limit how
many bytes to read at once.

In particular, i2c_smbus_read_i2c_block_data_or_emulated() takes the
length to read as an u8.  If count == 256 after taking into account the
offset and page boundary, the cast to u8 overflows.  And this is common
when user space tries to read the entire EEPROM at once.

To fix it, limit each read to I2C_SMBUS_BLOCK_MAX (32) bytes, already
the maximum length i2c_smbus_read_i2c_block_data_or_emulated() allows.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190
References: https://git.kernel.org/stable/c/3937c35493ee2847aaefcfa5460e94b7443eef49; https://git.kernel.org/stable/c/9443ddeb3754e9e382a396b50adc[PII_REDACTED]ce; https://git.kernel.org/stable/c/9a5f471ae380f9fcb9756d453c12ca1f8595a93c
CVE: CVE-2022-48807
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

ice: Fix KASAN error in LAG NETDEV_UNREGISTER handler

Currently, the same handler is called for both a NETDEV_BONDING_INFO
LAG unlink notification as for a NETDEV_UNREGISTER call.  This is
causing a problem though, since the netdev_notifier_info passed has
a different structure depending on which event is passed.  The problem
manifests as a call trace from a BUG: KASAN stack-out-of-bounds error.

Fix this by creating a handler specific to NETDEV_UNREGISTER that only
is passed valid elements in the netdev_notifier_info struct for the
NETDEV_UNREGISTER event.

Also included is the removal of an unbalanced dev_put on the peer_netdev
and related braces.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/bea1898f65b9b7096cb4e73e97c83b94718f1fa1; https://git.kernel.org/stable/c/f9daedc3ab8f673e3a9374b91a89fbf1174df469; https://git.kernel.org/stable/c/faa9bcf700ca1a0d09f92502a6b65d3ce313fb46
CVE: CVE-2022-48808
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: dsa: fix panic when DSA master device unbinds on shutdown

Rafael reports that on a system with LX2160A and Marvell DSA switches,
if a reboot occurs while the DSA master (dpaa2-eth) is up, the following
panic can be seen:

systemd-shutdown[1]: Rebooting.
Unable to handle kernel paging request at virtual address 00a[PII_REDACTED]041
[00a[PII_REDACTED]041] address between user and kernel address ranges
Internal error: Oops: 96000004 [#1] PREEMPT SMP
CPU: 6 PID: 1 Comm: systemd-shutdow Not tainted 5.16.5-00042-g8f5585009b24 #32
pc : dsa_slave_netdevice_event+0x130/0x3e4
lr : raw_notifier_call_chain+0x50/0x6c
Call trace:
 dsa_slave_netdevice_event+0x130/0x3e4
 raw_notifier_call_chain+0x50/0x6c
 call_netdevice_notifiers_info+0x54/0xa0
 __dev_close_many+0x50/0x130
 dev_close_many+0x84/0x120
 unregister_netdevice_many+0x130/0x710
 unregister_netdevice_queue+0x8c/0xd0
 unregister_netdev+0x20/0x30
 dpaa2_eth_remove+0x68/0x190
 fsl_mc_driver_remove+0x20/0x5c
 __device_release_driver+0x21c/0x220
 device_release_driver_internal+0xac/0xb0
 device_links_unbind_consumers+0xd4/0x100
 __device_release_driver+0x94/0x220
 device_release_driver+0x28/0x40
 bus_remove_device+0x118/0x124
 device_del+0x174/0x420
 fsl_mc_device_remove+0x24/0x40
 __fsl_mc_device_remove+0xc/0x20
 device_for_each_child+0x58/0xa0
 dprc_remove+0x90/0xb0
 fsl_mc_driver_remove+0x20/0x5c
 __device_release_driver+0x21c/0x220
 device_release_driver+0x28/0x40
 bus_remove_device+0x118/0x124
 device_del+0x174/0x420
 fsl_mc_bus_remove+0x80/0x100
 fsl_mc_bus_shutdown+0xc/0x1c
 platform_shutdown+0x20/0x30
 device_shutdown+0x154/0x330
 __do_sys_reboot+0x1cc/0x250
 __arm64_sys_reboot+0x20/0x30
 invoke_syscall.constprop.0+0x4c/0xe0
 do_el0_svc+0x4c/0x150
 el0_svc+0x24/0xb0
 el0t_64_sync_handler+0xa8/0xb0
 el0t_64_sync+0x178/0x17c

It can be seen from the stack trace that the problem is that the
deregistration of the master causes a dev_close(), which gets notified
as NETDEV_GOING_DOWN to dsa_slave_netdevice_event().
But dsa_switch_shutdown() has already run, and this has unregistered the
DSA slave interfaces, and yet, the NETDEV_GOING_DOWN handler attempts to
call dev_close_many() on those slave interfaces, leading to the problem.

The previous attempt to avoid the NETDEV_GOING_DOWN on the master after
dsa_switch_shutdown() was called seems improper. Unregistering the slave
interfaces is unnecessary and unhelpful. Instead, after the slaves have
stopped being uppers of the DSA master, we can now reset to NULL the
master->dsa_ptr pointer, which will make DSA start ignoring all future
notifier events on the master.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/89b60402d43cdab4387dbbf24afebda5cf092ae7; https://git.kernel.org/stable/c/ee534378f[PII_REDACTED]6663d[PII_REDACTED]8339ae; https://git.kernel.org/stable/c/ff45899e732e57088985e3a497b1d9100571c0f5
CVE: CVE-2022-48809
Published: 2024-07-16
Description: 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.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/00e6d6c3bc14dfe32824e2c515f0e0f2d6ecf2f1; https://git.kernel.org/stable/c/0be943916d781df2b652793bb2d3ae4f9624c10a; https://git.kernel.org/stable/c/4ac84498fbe84a00e7aef185e2bb3e40ce71eca4