deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-49171
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: don't BUG if someone dirty pages without asking ext4 first

[un]pin_user_pages_remote is dirtying pages without properly warning
the file system in advance.  A related race was noted by Jan Kara in
2018[1]; however, more recently instead of it being a very hard-to-hit
race, it could be reliably triggered by process_vm_writev(2) which was
discovered by Syzbot[2].

This is technically a bug in mm/gup.c, but arguably ext4 is fragile in
that if some other kernel subsystem dirty pages without properly
notifying the file system using page_mkwrite(), ext4 will BUG, while
other file systems will not BUG (although data will still be lost).

So instead of crashing with a BUG, issue a warning (since there may be
potential data loss) and just mark the page as clean to avoid
unprivileged denial of service attacks until the problem can be
properly fixed.  More discussion and background can be found in the
thread starting at [2].

[1] https://lore.kernel.org/linux-mm/[PII_REDACTED]0430.GE4911@quack2.suse.cz
[2] https://lore.kernel.org/r/Yg0m6IjcNmfaSokM@google.com
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-617
References: https://git.kernel.org/stable/c/0d3a6926f7e8be3c897fa46216ce13b119a9f56a; https://git.kernel.org/stable/c/330d0e44fc5a47c27df958ecdd4693a3cb1d8b81; https://git.kernel.org/stable/c/343117559ef41e992e326f7a92da1a8f254dfa8c
CVE: CVE-2022-49172
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

parisc: Fix non-access data TLB cache flush faults

When a page is not present, we get non-access data TLB faults from
the fdc and fic instructions in flush_user_dcache_range_asm and
flush_user_icache_range_asm. When these occur, the cache line is
not invalidated and potentially we get memory corruption. The
problem was hidden by the nullification of the flush instructions.

These faults also affect performance. With pa8800/pa8900 processors,
there will be 32 faults per 4 KB page since the cache line is 128
bytes.  There will be more faults with earlier processors.

The problem is fixed by using flush_cache_pages(). It does the flush
using a tmp alias mapping.

The flush_cache_pages() call in flush_cache_range() flushed too
large a range.

V2: Remove unnecessary preempt_disable() and preempt_enable() calls.
CVSS Score: 7.1 (HIGH)
References: https://git.kernel.org/stable/c/b3d6adb3a49d82e4e557c5fc16f50c9ff731da5d; https://git.kernel.org/stable/c/ddca4b82027e2a66333dd40fab21a4beff435c7e; https://git.kernel.org/stable/c/f839e5f1cef36ce268950c387129b1bfefdaebc9
CVE: CVE-2022-49173
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

spi: fsi: Implement a timeout for polling status

The data transfer routines must poll the status register to
determine when more data can be shifted in or out. If the hardware
gets into a bad state, these polling loops may never exit. Prevent
this by returning an error if a timeout is exceeded.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/89b35e3f28514087d3f1e28e8f5634fbfd07c554; https://git.kernel.org/stable/c/d4982ceb137e6ecd2b466a6de639790a148cf19a; https://git.kernel.org/stable/c/dac1438f347d3b8cf892105c94e254f29c5764de
CVE: CVE-2022-49174
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: fix ext4_mb_mark_bb() with flex_bg with fast_commit

In case of flex_bg feature (which is by default enabled), extents for
any given inode might span across blocks from two different block group.
ext4_mb_mark_bb() only reads the buffer_head of block bitmap once for the
starting block group, but it fails to read it again when the extent length
boundary overflows to another block group. Then in this below loop it
accesses memory beyond the block group bitmap buffer_head and results
into a data abort.

	for (i = 0; i < clen; i++)
		if (!mb_test_bit(blkoff + i, bitmap_bh->b_data) == !state)
			already++;

This patch adds this functionality for checking block group boundary in
ext4_mb_mark_bb() and update the buffer_head(bitmap_bh) for every different
block group.

w/o this patch, I was easily able to hit a data access abort using Power platform.

<...>
[   74.327662] EXT4-fs error (device loop3): ext4_mb_generate_buddy:1141: group 11, block bitmap and bg descriptor inconsistent: 21248 vs 23294 free clusters
[   74.533214] EXT4-fs (loop3): shut down requested (2)
[   74.536705] Aborting journal on device loop3-8.
[   74.702705] BUG: Unable to handle kernel data access on read at 0xc00000005e980000
[   74.703727] Faulting instruction address: 0xc[PII_REDACTED]bffb8
cpu 0xd: Vector: 300 (Data Access) at [c000000015db7060]
    pc: c[PII_REDACTED]bffb8: ext4_mb_mark_bb+0x198/0x5a0
    lr: c[PII_REDACTED]bfeec: ext4_mb_mark_bb+0xcc/0x5a0
    sp: c000000015db7300
   msr:[PII_REDACTED]80b033
   dar: c00000005e980000
 dsisr: 40000000
  current = 0xc000000027af6880
  paca    = 0xc00000003ffd5200   irqmask: 0x03   irq_happened: 0x01
    pid   = 5167, comm = mount
<...>
enter ? for help
[c000000015db7380] c[PII_REDACTED]82708 ext4_ext_clear_bb+0x378/0x410
[c000000015db7400] c[PII_REDACTED]13f14 ext4_fc_replay+0x1794/0x2000
[c000000015db7580] c[PII_REDACTED]33f7c do_one_pass+0xe9c/0x12a0
[c000000015db7710] c[PII_REDACTED]34504 jbd2_journal_recover+0x184/0x2d0
[c000000015db77c0] c[PII_REDACTED]41398 jbd2_journal_load+0x188/0x4a0
[c000000015db7880] c[PII_REDACTED]04de8 ext4_fill_super+0x2638/0x3e10
[c000000015db7a40] c[PII_REDACTED]f8404 get_tree_bdev+0x2b4/0x350
[c000000015db7ae0] c[PII_REDACTED]ef058 ext4_get_tree+0x28/0x40
[c000000015db7b00] c[PII_REDACTED]f6344 vfs_get_tree+0x44/0x100
[c000000015db7b70] c[PII_REDACTED]3c408 path_mount+0xdd8/0xe70
[c000000015db7c40] c[PII_REDACTED]3c8f0 sys_mount+0x450/0x550
[c000000015db7d50] c[PII_REDACTED]35770 system_call_exception+0x4a0/0x4e0
[c000000015db7e10] c[PII_REDACTED]0c74c system_call_common+0xec/0x250
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/6a6beb074186a0452368a023a261c7d0eaebe838; https://git.kernel.org/stable/c/803fb0e8240cc16585a5c9df76add1dfaa781773; https://git.kernel.org/stable/c/b07eedd0222e9548ffc568ec429bb1f61d21a39c
CVE: CVE-2022-49177
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

hwrng: cavium - fix NULL but dereferenced coccicheck error

Fix following coccicheck warning:
./drivers/char/hw_random/cavium-rng-vf.c:182:17-20: ERROR:
pdev is NULL but dereferenced.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/e47b12f9415169eceda6770fcf45802e0c8d2a66; https://git.kernel.org/stable/c/e6205ad58a7ac194abfb33897585b38687d797fa
CVE: CVE-2022-49178
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

memstick/mspro_block: fix handling of read-only devices

Use set_disk_ro to propagate the read-only state to the block layer
instead of checking for it in ->open and leaking a reference in case
of a read-only device.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/057b53c4f87690d626203acef8b63d52a9bf2f43; https://git.kernel.org/stable/c/6a0725b9d78ff6efdc95a37e4f05072e79c63918; https://git.kernel.org/stable/c/6dab421bfe06a59bf8f212a72e34673e8acf2018
CVE: CVE-2022-49180
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

LSM: general protection fault in legacy_parse_param

The usual LSM hook "bail on fail" scheme doesn't work for cases where
a security module may return an error code indicating that it does not
recognize an input.  In this particular case Smack sees a mount option
that it recognizes, and returns 0. A call to a BPF hook follows, which
returns -ENOPARAM, which confuses the caller because Smack has processed
its data.

The SELinux hook incorrectly returns 1 on success. There was a time
when this was correct, however the current expectation is that it
return 0 on success. This is repaired.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/00fc07fa0b4a004711b6e1a944f0d2e46f7093b7; https://git.kernel.org/stable/c/2784604c8c6fc523248f8f80a421c313a9d790b7; https://git.kernel.org/stable/c/cadae7c5e477aaafcba819b8e4a3d1c1a1503b62
CVE: CVE-2022-49181
Published: 2025-02-26
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2022-49182
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

net: hns3: add vlan list lock to protect vlan list

When adding port base VLAN, vf VLAN need to remove from HW and modify
the vlan state in vf VLAN list as false. If the periodicity task is
freeing the same node, it may cause "use after free" error.
This patch adds a vlan list lock to protect the vlan list.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/09e383ca97e798f9954189b741af54b5c51e7a97; https://git.kernel.org/stable/c/1932a624ab88ff407d1a1d567fe581faa15dc725; https://git.kernel.org/stable/c/30f0ff7176efe8ac6c55f85bce26ed58bb608758
CVE: CVE-2022-49183
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

net/sched: act_ct: fix ref leak when switching zones

When switching zones or network namespaces without doing a ct clear in
between, it is now leaking a reference to the old ct entry. That's
because tcf_ct_skb_nfct_cached() returns false and
tcf_ct_flow_table_lookup() may simply overwrite it.

The fix is to, as the ct entry is not reusable, free it already at
tcf_ct_skb_nfct_cached().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/4bb42d73def9411e5cad885b9811987d72431df1; https://git.kernel.org/stable/c/b24793a37d91aacad7cb9893b226a7924a89636a; https://git.kernel.org/stable/c/bcb74e132a76ce0502bb33d5b65533a4ed72d159
CVE: CVE-2022-49184
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

net: sparx5: switchdev: fix possible NULL pointer dereference

As the possible failure of the allocation, devm_kzalloc() may return NULL
pointer.
Therefore, it should be better to check the 'db' in order to prevent
the dereference of NULL pointer.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/0906f3a3df07835e37077d8971aac65347f2ed57; https://git.kernel.org/stable/c/b375ea083fa649092cd016ac1f89a2d1fd8f8e8b; https://git.kernel.org/stable/c/c346791877e6ce923bb21e34b30c6f99326aa5a8
CVE: CVE-2022-49185
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

pinctrl: nomadik: Add missing of_node_put() in nmk_pinctrl_probe

This node pointer is returned by of_parse_phandle() with refcount
incremented in this function. Calling of_node_put() to avoid
the refcount leak.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0067ba448f1c29ca06e5aee00d8506889ed1f9d0; https://git.kernel.org/stable/c/0356d4b64a03d23daf99a2a29d7d7d91d6ec2ea8; https://git.kernel.org/stable/c/59250d547542f1c7765a78dc97ddfe5e6b0d2ab0
CVE: CVE-2022-49186
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: visconti: prevent array overflow in visconti_clk_register_gates()

This code was using -1 to represent that there was no reset function.
Unfortunately, the -1 was stored in u8 so the if (clks[i].rs_id >= 0)
condition was always true.  This lead to an out of bounds access in
visconti_clk_register_gates().
CVSS Score: 7.8 (HIGH)
CWE: CWE-129, CWE-129
References: https://git.kernel.org/stable/c/2723543c1d60278d5aef1c4ad732dbad24b84a81; https://git.kernel.org/stable/c/c5601e0720ce1a3ad895f94a5838530edde01ed3
CVE: CVE-2022-49187
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: Fix clk_hw_get_clk() when dev is NULL

Any registered clk_core structure can have a NULL pointer in its dev
field. While never actually documented, this is evidenced by the wide
usage of clk_register and clk_hw_register with a NULL device pointer,
and the fact that the core of_clk_hw_register() function also passes a
NULL device pointer.

A call to clk_hw_get_clk() on a clk_hw struct whose clk_core is in that
case will result in a NULL pointer derefence when it calls dev_name() on
that NULL device pointer.

Add a test for this case and use NULL as the dev_id if the device
pointer is NULL.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/0c1b56df451716ba207bbf59f303473643eee4fd; https://git.kernel.org/stable/c/23f89fe005b105f0dcc55034c13eb89f9b570fac; https://git.kernel.org/stable/c/4be3e4c05d8dd1b83b75652cad88c9e752ec7054
CVE: CVE-2022-49188
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

remoteproc: qcom_q6v5_mss: Fix some leaks in q6v5_alloc_memory_region

The device_node pointer is returned by of_parse_phandle() or
of_get_child_by_name() with refcount incremented.
We should use of_node_put() on it when done.

This function only call of_node_put(node) when of_address_to_resource
succeeds, missing error cases.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/07a5dcc4bed9d7cae54adf5aa10ff9f037a3204b; https://git.kernel.org/stable/c/a7d988735e757e111f9722de7cf1b40a84a48b1f; https://git.kernel.org/stable/c/b9df3007b3cda4936cc50f5a7d2d30505a652828
CVE: CVE-2022-49189
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: qcom: clk-rcg2: Update logic to calculate D value for RCG

The display pixel clock has a requirement on certain newer platforms to
support M/N as (2/3) and the final D value calculated results in
underflow errors.
As the current implementation does not check for D value is within
the accepted range for a given M & N value. Update the logic to
calculate the final D value based on the range.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/334720f418f57b1d969dad2117b21f9388cb9395; https://git.kernel.org/stable/c/34dca60982e93e69ae442aa2d36ce61c9a3bb563; https://git.kernel.org/stable/c/52592f9afbfe01bce8f8953e4f19cbe3bcbdbd3a
CVE: CVE-2022-49190
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

kernel/resource: fix kfree() of bootmem memory again

Since commit ebff7d8f270d ("mem hotunplug: fix kfree() of bootmem
memory"), we could get a resource allocated during boot via
alloc_resource().  And it's required to release the resource using
free_resource().  Howerver, many people use kfree directly which will
result in kernel BUG.  In order to fix this without fixing every call
site, just leak a couple of bytes in such corner case.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/0cbcc92917c5de80f15c24d033566539ad696892; https://git.kernel.org/stable/c/3379a60f6bb4afcd9c456e340ac525ae649d3ce7; https://git.kernel.org/stable/c/a9e88c2618d228d7a4e7e515cf30dc0d0d813f27
CVE: CVE-2022-49191
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

mxser: fix xmit_buf leak in activate when LSR == 0xff

When LSR is 0xff in ->activate() (rather unlike), we return an error.
Provided ->shutdown() is not called when ->activate() fails, nothing
actually frees the buffer in this case.

Fix this by properly freeing the buffer in a designated label. We jump
there also from the "!info->type" if now too.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/125b7c929fc9b1e5eaa344bceb6367dfa6fd3f9d; https://git.kernel.org/stable/c/2cd05c38a27bee7fb42aa4d43174d68ac55dac0f; https://git.kernel.org/stable/c/[PII_REDACTED]09f8ea2d20a8fa3475e95b47c41690
CVE: CVE-2022-49192
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drivers: ethernet: cpsw: fix panic when interrupt coaleceing is set via ethtool

cpsw_ethtool_begin directly returns the result of pm_runtime_get_sync
when successful.
pm_runtime_get_sync returns -error code on failure and 0 on successful
resume but also 1 when the device is already active. So the common case
for cpsw_ethtool_begin is to return 1. That leads to inconsistent calls
to pm_runtime_put in the call-chain so that pm_runtime_put is called
one too many times and as result leaving the cpsw dev behind suspended.

The suspended cpsw dev leads to an access violation later on by
different parts of the cpsw driver.

Fix this by calling the return-friendly pm_runtime_resume_and_get
function.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2844e[PII_REDACTED]f674d1fb4130c308c50ba681e; https://git.kernel.org/stable/c/30ad11bff021a94aff6dab1ec9236fdfd884fbff; https://git.kernel.org/stable/c/459080fab12b23c0526026e5cedbf3fabb5457cc
CVE: CVE-2022-49193
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ice: fix 'scheduling while atomic' on aux critical err interrupt

There's a kernel BUG splat on processing aux critical error
interrupts in ice_misc_intr():

[ 2100.917085] BUG: scheduling while atomic: swapper/15/0/0x00010000
...
[ 2101.060770] Call Trace:
[ 2101.063229]  <IRQ>
[ 2101.065252]  dump_stack+0x41/0x60
[ 2101.068587]  __schedule_bug.cold.100+0x4c/0x58
[ 2101.073060]  __schedule+0x6a4/0x830
[ 2101.076570]  schedule+0x35/0xa0
[ 2101.079727]  schedule_preempt_disabled+0xa/0x10
[ 2101.084284]  __mutex_lock.isra.7+0x310/0x420
[ 2101.088580]  ? ice_misc_intr+0x201/0x2e0 [ice]
[ 2101.093078]  ice_send_event_to_aux+0x25/0x70 [ice]
[ 2101.097921]  ice_misc_intr+0x220/0x2e0 [ice]
[ 2101.102232]  __handle_irq_event_percpu+0x40/0x180
[ 2101.106965]  handle_irq_event_percpu+0x30/0x80
[ 2101.111434]  handle_irq_event+0x36/0x53
[ 2101.115292]  handle_edge_irq+0x82/0x190
[ 2101.119148]  handle_irq+0x1c/0x30
[ 2101.122480]  do_IRQ+0x49/0xd0
[ 2101.125465]  common_interrupt+0xf/0xf
[ 2101.129146]  </IRQ>
...

As Andrew correctly mentioned previously[0], the following call
ladder happens:

ice_misc_intr() <- hardirq
  ice_send_event_to_aux()
    device_lock()
      mutex_lock()
        might_sleep()
          might_resched() <- oops

Add a new PF state bit which indicates that an aux critical error
occurred and serve it in ice_service_task() in process context.
The new ice_pf::oicr_err_reg is read-write in both hardirq and
process contexts, but only 3 bits of non-critical data probably
aren't worth explicit synchronizing (and they're even in the same
byte [31:24]).

[0] https://lore.kernel.org/all/YeSRUVmrdmlUXHDn@lunn.ch
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/24d7ac8426306ae7ccea7f7dd612a7368fe7201d; https://git.kernel.org/stable/c/32d53c0aa3a7b[PII_REDACTED]49bad2a830b908edc; https://git.kernel.org/stable/c/59e88a50afad7469c55804e46bf2924b9130281f
CVE: CVE-2022-49195
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

net: dsa: fix panic on shutdown if multi-chip tree failed to probe

DSA probing is atypical because a tree of devices must probe all at
once, so out of N switches which call dsa_tree_setup_routing_table()
during probe, for (N - 1) of them, "complete" will return false and they
will exit probing early. The Nth switch will set up the whole tree on
their behalf.

The implication is that for (N - 1) switches, the driver binds to the
device successfully, without doing anything. When the driver is bound,
the ->shutdown() method may run. But if the Nth switch has failed to
initialize the tree, there is nothing to do for the (N - 1) driver
instances, since the slave devices have not been created, etc. Moreover,
dsa_switch_shutdown() expects that the calling @ds has been in fact
initialized, so it jumps at dereferencing the various data structures,
which is incorrect.

Avoid the ensuing NULL pointer dereferences by simply checking whether
the Nth switch has previously set "ds->setup = true" for the switch
which is currently shutting down. The entire setup is serialized under
dsa2_mutex which we already hold.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/8fd36358ce82382519b50b05f437493e1e00c4a9; https://git.kernel.org/stable/c/95df5cd5a446df6738d2d45872e[PII_REDACTED]0e4; https://git.kernel.org/stable/c/b6e668ff43ebd87ccc8a19e5481345c428672295
CVE: CVE-2022-49197
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

af_netlink: Fix shift out of bounds in group mask calculation

When a netlink message is received, netlink_recvmsg() fills in the address
of the sender. One of the fields is the 32-bit bitfield nl_groups, which
carries the multicast group on which the message was received. The least
significant bit corresponds to group 1, and therefore the highest group
that the field can represent is 32. Above that, the UB sanitizer flags the
out-of-bounds shift attempts.

Which bits end up being set in such case is implementation defined, but
it's either going to be a wrong non-zero value, or zero, which is at least
not misleading. Make the latter choice deterministic by always setting to 0
for higher-numbered multicast groups.

To get information about membership in groups >= 32, userspace is expected
to use nl_pktinfo control messages[0], which are enabled by NETLINK_PKTINFO
socket option.
[0] https://lwn.net/Articles/147608/

The way to trigger this issue is e.g. through monitoring the BRVLAN group:

	# bridge monitor vlan &
	# ip link add name br type bridge

Which produces the following citation:

	UBSAN: shift-out-of-bounds in net/netlink/af_netlink.c:162:19
	shift exponent 32 is too large for 32-bit type 'int'
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190
References: https://git.kernel.org/stable/c/0caf6d9922192dd1afa8dc2131abfb4df1443b9f; https://git.kernel.org/stable/c/41249fff507387c3323b198d0052faed08b14de4; https://git.kernel.org/stable/c/7409ff6393a67ff9838d0ae1bd102fb5f020d07a
CVE: CVE-2022-49198
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

mptcp: Fix crash due to tcp_tsorted_anchor was initialized before release skb

Got crash when doing pressure test of mptcp:

===========================================================================
dst_release: dst:ffffa06ce6e5c058 refcnt:-1
kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
BUG: unable to handle kernel paging request at ffffa06ce6e5c058
PGD 190a01067 P4D 190a01067 PUD 43fffb067 PMD 22e403063 PTE[PII_REDACTED]e5c063
Oops: 0011 [#1] SMP PTI
CPU: 7 PID: 7823 Comm: kworker/7:0 Kdump: loaded Tainted: G            E
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.2.1 04/01/2014
Call Trace:
 ? skb_release_head_state+0x68/0x100
 ? skb_release_all+0xe/0x30
 ? kfree_skb+0x32/0xa0
 ? mptcp_sendmsg_frag+0x57e/0x750
 ? __mptcp_retrans+0x21b/0x3c0
 ? __switch_to_asm+0x35/0x70
 ? mptcp_worker+0x25e/0x320
 ? process_one_work+0x1a7/0x360
 ? worker_thread+0x30/0x390
 ? create_worker+0x1a0/0x1a0
 ? kthread+0x112/0x130
 ? kthread_flush_work_fn+0x10/0x10
 ? ret_from_fork+0x35/0x40
===========================================================================

In __mptcp_alloc_tx_skb skb was allocated and skb->tcp_tsorted_anchor will
be initialized, in under memory pressure situation sk_wmem_schedule will
return false and then kfree_skb. In this case skb->_skb_refdst is not null
because_skb_refdst and tcp_tsorted_anchor are stored in the same mem, and
kfree_skb will try to release dst and cause crash.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3ef3905aa3b5b3e222ee6eb0210bfd999417a8cc; https://git.kernel.org/stable/c/4d54181eba4b077fb74033a7186898ad4000a7a5; https://git.kernel.org/stable/c/752add6f5ce5305e55d8bda4ac8d69be3a09f14d