huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2022-50054: kernel: iavf: Fix NULL pointer dereference in iavf_get_link_ksettings
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-06-18T00:00:00+00:00

A flaw was found in the iavf module in the Linux kernel. A NULL pointer dereference can be triggered due to improper error management, resulting in a denial of service.

Statement: This issue has been fixed in Red Hat Enterprise Linux 8.6, 8.7, 9.1 and 9.2 via RHSA-2022:7110 [1], RHSA-2022:7683 [2], RHSA-2023:0334 [3] and RHSA-2023:2458 [4], respectively.

[1]. https://access.redhat.com/errata/RHSA-2022:7110

[2]. https://access.redhat.com/errata/RHSA-2022:7683

[3]. https://access.redhat.com/errata/RHSA-2023:0334

[4]. https://access.redhat.com/errata/RHSA-2023:2458

Affected upstream versions: 5.17
Fixed upstream versions: 0, 5.19.4, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: b305c7e9363f5a174ee08ac5f056e4b209f0325b
CVE-2022-50055: kernel: iavf: Fix adminq error handling
Component: kernel
Severity: Low
CVSS v3: 4.7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

iavf: Fix adminq error handling

iavf_alloc_asq_bufs/iavf_alloc_arq_bufs allocates with dma_alloc_coherent
memory for VF mailbox.
Free DMA regions for both ASQ and ARQ in case error happens during
configuration of ASQ/ARQ registers.
Without this change it is possible to see when unloading interface:
74626.583369: dma_debug_device_change: device driver has pending DMA allocations while released from device [count=32]
One of leaked entries details: [device address=0x0000000b27ff9000] [size=4096 bytes] [mapped with DMA_BIDIRECTIONAL] [mapped as coherent]


Affected upstream versions: 3.14
Fixed upstream versions: 0, 5.10.138, 5.15.63, 5.19.4, 5.4.211, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: ff289f2be5899efd0e897d2b434a78e36df2c69b
CVE-2022-50058: kernel: vdpa_sim_blk: set number of address spaces and virtqueue groups
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

vdpa_sim_blk: set number of address spaces and virtqueue groups

Commit bda324fd037a ("vdpasim: control virtqueue support") added two
new fields (nas, ngroups) to vdpasim_dev_attr, but we forgot to
initialize them for vdpa_sim_blk.

When creating a new vdpa_sim_blk device this causes the kernel
to panic in this way:
    $ vdpa dev add mgmtdev vdpasim_blk name blk0
    BUG: kernel NULL pointer dereference, address: 0000000000000030
    ...
    RIP: 0010:vhost_iotlb_add_range_ctx+0x41/0x220 [vhost_iotlb]
    ...
    Call Trace:
     <TASK>
     vhost_iotlb_add_range+0x11/0x800 [vhost_iotlb]
     vdpasim_map_range+0x91/0xd0 [vdpa_sim]
     vdpasim_alloc_coherent+0x56/0x90 [vdpa_sim]
     ...

This happens because vdpasim->iommu[0] is not initialized when
dev_attr.nas is 0.

Let's fix this issue by initializing both (nas, ngroups) to 1 for
vdpa_sim_blk.


Affected upstream versions: 5.19
Fixed upstream versions: 0, 5.19.4, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: a291c7d289fac2cb13fb2614a9a251afbbd86ce9
CVE-2022-50066: kernel: net: atlantic: fix aq_vec index out of range error
Component: kernel
Severity: Moderate
CWE: CWE-823 (Use of Out-of-range Pointer Offset)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

A vulnerability was found in the Linux kernel's Aquantia Atlantic driver, where a lack of proper bounds checking during loop indexing can lead to an out-of-bounds access. This can lead to undefined system behavior and a denial of service.

Statement: This vulnerability in the Aquantia network driver (atlantic) allows out-of-bounds access to the aq_vec[] array, which can lead to a kernel crash. However, triggering this issue requires privileges, as it occurs in internal kernel functions like aq_nic_stop() and aq_vec_isr(), typically invoked during device suspend or shutdown. This bug was observable through a UBSAN report in aq_nic_stop().

Affected upstream versions: 4.11
Fixed upstream versions: 0, 5.10.138, 5.15.63, 5.19.4, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: df60c534d4c5a681172952dd4b475a5d818b3a86
CVE-2022-50068: kernel: drm/ttm: Fix dummy res NULL ptr deref bug
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-06-18T00:00:00+00:00

A flaw was found in the ttm module in the Linux kernel. A NULL pointer dereference can be triggered due to an improper check, resulting in a denial of service.

Statement: This issue has been fixed in Red Hat Enterprise Linux 8.8 and 9.2 via RHSA-2023:2951 [1] and RHSA-2023:2458 [2], respectively.

[1]. https://access.redhat.com/errata/RHSA-2023:2951

[2]. https://access.redhat.com/errata/RHSA-2023:2458

Affected upstream versions: 5.14
Fixed upstream versions: 0, 5.15.63, 5.19.4, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 76672cd326c146ded2c2712ff257b8908dcf23d8
CVE-2022-50070: kernel: mptcp: do not queue data on closed subflows
Component: kernel
Severity: Moderate
CWE: CWE-825 (Expired Pointer Dereference)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

mptcp: do not queue data on closed subflows

Dipanjan reported a syzbot splat at close time:

WARNING: CPU: 1 PID: 10818 at net/ipv4/af_inet.c:153
inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153
Modules linked in: uio_ivshmem(OE) uio(E)
CPU: 1 PID: 10818 Comm: kworker/1:16 Tainted: G           OE
5.19.0-rc6-g2eae0556bb9d #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153
Code: 21 02 00 00 41 8b 9c 24 28 02 00 00 e9 07 ff ff ff e8 34 4d 91
f9 89 ee 4c 89 e7 e8 4a 47 60 ff e9 a6 fc ff ff e8 20 4d 91 f9 <0f> 0b
e9 84 fe ff ff e8 14 4d 91 f9 0f 0b e9 d4 fd ff ff e8 08 4d
RSP: 0018:ffffc9001b35fa78 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00000000002879d0 RCX: ffff8881326f3b00
RDX: 0000000000000000 RSI: ffff8881326f3b00 RDI: 0000000000000002
RBP: ffff888179662674 R08: ffffffff87e983a0 R09: 0000000000000000
R10: 0000000000000005 R11: 00000000000004ea R12: ffff888179662400
R13: ffff888179662428 R14: 0000000000000001 R15: ffff88817e38e258
FS:  0000000000000000(0000) GS:ffff8881f5f00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020007bc0 CR3: 0000000179592000 CR4: 0000000000150ee0
Call Trace:
 <TASK>
 __sk_destruct+0x4f/0x8e0 net/core/sock.c:2067
 sk_destruct+0xbd/0xe0 net/core/sock.c:2112
 __sk_free+0xef/0x3d0 net/core/sock.c:2123
 sk_free+0x78/0xa0 net/core/sock.c:2134
 sock_put include/net/sock.h:1927 [inline]
 __mptcp_close_ssk+0x50f/0x780 net/mptcp/protocol.c:2351
 __mptcp_destroy_sock+0x332/0x760 net/mptcp/protocol.c:2828
 mptcp_worker+0x5d2/0xc90 net/mptcp/protocol.c:2586
 process_one_work+0x9cc/0x1650 kernel/workqueue.c:2289
 worker_thread+0x623/0x1070 kernel/workqueue.c:2436
 kthread+0x2e9/0x3a0 kernel/kthread.c:376
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302
 </TASK>

The root cause of the problem is that an mptcp-level (re)transmit can
race with mptcp_close() and the packet scheduler checks the subflow
state before acquiring the socket lock: we can try to (re)transmit on
an already closed ssk.

Fix the issue checking again the subflow socket status under the
subflow socket lock protection. Additionally add the missing check
for the fallback-to-tcp case.


Affected upstream versions: 5.10
Fixed upstream versions: 0, 5.15.190, 5.19.4, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: fb9c73ef2ac2ec816efdc8b9267bc04e1369c20b
CVE-2022-50072: kernel: NFSv4/pnfs: Fix a use-after-free bug in open
Component: kernel
Severity: Moderate
CWE: CWE-763 (Release of Invalid Pointer or Reference)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

NFSv4/pnfs: Fix a use-after-free bug in open

If someone cancels the open RPC call, then we must not try to free
either the open slot or the layoutget operation arguments, since they
are likely still in use by the hung RPC call.


Affected upstream versions: 4.19.247 < 4.19.256, 5.4.198 < 5.4.211, 5.10.122 < 5.10.138, 5.15.47 < 5.15.63, 5.17.15 < 5.18, 5.18.4 < 5.19, 5.19
Fixed upstream versions: 0, 4.19.256, 5.10.138, 5.15.63, 5.18, 5.19, 5.19.4, 5.4.211, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 0fffb46ff3d5ed4668aca96441ec7a25b793bd6f
CVE-2022-50073: kernel: net: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is null
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-06-18T00:00:00+00:00

A flaw was found in the tap module in the Linux kernel. A NULL pointer dereference can be triggered due to a missing initialization, resulting in a denial of service.

Statement: This issue has been fixed in Red Hat Enterprise Linux 8.5 and 9.5 via RHSA-2021:4356 [1] and RHSA-2024:9315 [2], respectively.

[1]. https://access.redhat.com/errata/RHSA-2021:4356

[2]. https://access.redhat.com/errata/RHSA-2024:9315

Affected upstream versions: 5.10.24 < 5.10.258, 4.14.226 < 4.15, 4.19.181 < 4.20, 5.4.106 < 5.5, 5.11.7 < 5.12, 5.12
Fixed upstream versions: 0, 4.15, 4.20, 5.10.258, 5.12, 5.15.209, 5.19.4, 5.5, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 8f90163f9e013c8fc791aab338aab44a46044cfc
CVE-2022-50079: kernel: drm/amd/display: Check correct bounds for stream encoder instances for DCN303
Component: kernel
Severity: Moderate
CWE: CWE-125 (Out-of-bounds Read)
CVSS v3: 6.5 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check correct bounds for stream encoder instances for DCN303

[Why & How]
eng_id for DCN303 cannot be more than 1, since we have only two
instances of stream encoders.

Check the correct boundary condition for engine ID for DCN303 prevent
the potential out of bounds access.


Affected upstream versions: 5.14
Fixed upstream versions: 0, 5.15.63, 5.19.4, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 82a27c1855445d48aacc67b0c0640f3dadebe52f
CVE-2022-50080: kernel: tee: add overflow check in register_shm_helper()
Component: kernel
Severity: Moderate
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

tee: add overflow check in register_shm_helper()

With special lengths supplied by user space, register_shm_helper() has
an integer overflow when calculating the number of pages covered by a
supplied user space memory region.

This causes internal_get_user_pages_fast() a helper function of
pin_user_pages_fast() to do a NULL pointer dereference:

  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
  Modules linked in:
  CPU: 1 PID: 173 Comm: optee_example_a Not tainted 5.19.0 #11
  Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
  pc : internal_get_user_pages_fast+0x474/0xa80
  Call trace:
   internal_get_user_pages_fast+0x474/0xa80
   pin_user_pages_fast+0x24/0x4c
   register_shm_helper+0x194/0x330
   tee_shm_register_user_buf+0x78/0x120
   tee_ioctl+0xd0/0x11a0
   __arm64_sys_ioctl+0xa8/0xec
   invoke_syscall+0x48/0x114

Fix this by adding an an explicit call to access_ok() in
tee_shm_register_user_buf() to catch an invalid user space address
early.


Affected upstream versions: 4.16
Fixed upstream versions: 0, 4.19.256, 5.10.137, 5.15.62, 5.18.19, 5.19.3, 5.4.211, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: b37e0f17653c00b586cdbcdf0dbca475358ecffd
CVE-2022-50084: kernel: dm raid: fix address sanitizer warning in raid_status
Component: kernel
Severity: Low
CWE: CWE-843 (Access of Resource Using Incompatible Type ('Type Confusion'))
CVSS v3: 3.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

dm raid: fix address sanitizer warning in raid_status

There is this warning when using a kernel with the address sanitizer
and running this testsuite:
https://gitlab.com/cki-project/kernel-tests/-/tree/main/storage/swraid/scsi_raid

==================================================================
BUG: KASAN: slab-out-of-bounds in raid_status+0x1747/0x2820 [dm_raid]
Read of size 4 at addr ffff888079d2c7e8 by task lvcreate/13319
CPU: 0 PID: 13319 Comm: lvcreate Not tainted 5.18.0-0.rc3.<snip> #1
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
Call Trace:
 <TASK>
 dump_stack_lvl+0x6a/0x9c
 print_address_description.constprop.0+0x1f/0x1e0
 print_report.cold+0x55/0x244
 kasan_report+0xc9/0x100
 raid_status+0x1747/0x2820 [dm_raid]
 dm_ima_measure_on_table_load+0x4b8/0xca0 [dm_mod]
 table_load+0x35c/0x630 [dm_mod]
 ctl_ioctl+0x411/0x630 [dm_mod]
 dm_ctl_ioctl+0xa/0x10 [dm_mod]
 __x64_sys_ioctl+0x12a/0x1a0
 do_syscall_64+0x5b/0x80

The warning is caused by reading conf->max_nr_stripes in raid_status. The
code in raid_status reads mddev->private, casts it to struct r5conf and
reads the entry max_nr_stripes.

However, if we have different raid type than 4/5/6, mddev->private
doesn't point to struct r5conf; it may point to struct r0conf, struct
r1conf, struct r10conf or struct mpconf. If we cast a pointer to one
of these structs to struct r5conf, we will be reading invalid memory
and KASAN warns about it.

Fix this bug by reading struct r5conf only if raid type is 4, 5 or 6.


Affected upstream versions: 4.8
Fixed upstream versions: 0, 4.14.291, 4.19.256, 4.9.326, 5.10.137, 5.15.61, 5.18.18, 5.19.2, 5.4.211, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 1ae0ebfb576b72c2ef400917a5484ebe7892d80b
CVE-2022-50085: kernel: dm raid: fix address sanitizer warning in raid_resume
Component: kernel
Severity: Low
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

dm raid: fix address sanitizer warning in raid_resume

There is a KASAN warning in raid_resume when running the lvm test
lvconvert-raid.sh. The reason for the warning is that mddev->raid_disks
is greater than rs->raid_disks, so the loop touches one entry beyond
the allocated length.


Affected upstream versions: 4.8
Fixed upstream versions: 0, 4.14.291, 4.19.256, 5.10.137, 5.15.61, 5.18.18, 5.19.2, 5.4.211, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: c2f075e729636a44e98d9722e3852c2fa6fa49b6
CVE-2022-50086: kernel: block: don't allow the same type rq_qos add more than once
Component: kernel
Severity: Moderate
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

block: don't allow the same type rq_qos add more than once

In our test of iocost, we encountered some list add/del corruptions of
inner_walk list in ioc_timer_fn.

The reason can be described as follows:

cpu 0					cpu 1
ioc_qos_write				ioc_qos_write

ioc = q_to_ioc(queue);
if (!ioc) {
        ioc = kzalloc();
					ioc = q_to_ioc(queue);
					if (!ioc) {
						ioc = kzalloc();
						...
						rq_qos_add(q, rqos);
					}
        ...
        rq_qos_add(q, rqos);
        ...
}

When the io.cost.qos file is written by two cpus concurrently, rq_qos may
be added to one disk twice. In that case, there will be two iocs enabled
and running on one disk. They own different iocgs on their active list. In
the ioc_timer_fn function, because of the iocgs from two iocs have the
same root iocg, the root iocg's walk_list may be overwritten by each other
and this leads to list add/del corruptions in building or destroying the
inner_walk list.

And so far, the blk-rq-qos framework works in case that one instance for
one type rq_qos per queue by default. This patch make this explicit and
also fix the crash above.


Affected upstream versions: 4.19
Fixed upstream versions: 0, 5.15.61, 5.18.18, 5.19.2, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 0b7f5d7a4d2a72ad9de04ab8ccba2a31904aa638
CVE-2022-50087: kernel: firmware: arm_scpi: Ensure scpi_info is not assigned if the probe fails
Component: kernel
Severity: Moderate
CWE: CWE-825 (Expired Pointer Dereference)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

firmware: arm_scpi: Ensure scpi_info is not assigned if the probe fails

When scpi probe fails, at any point, we need to ensure that the scpi_info
is not set and will remain NULL until the probe succeeds. If it is not
taken care, then it could result use-after-free as the value is exported
via get_scpi_ops() and could refer to a memory allocated via devm_kzalloc()
but freed when the probe fails.

Statement: This vulnerability is rated Moderate for Red Hat Enterprise Linux 8 and 9. A use-after-free flaw in the `arm_scpi` firmware component of the Linux kernel could allow a local attacker to escalate privileges. Triggering this vulnerability requires precise timing conditions that need to coincide with the rare event of an scpi probe failure; scpi probes are typically only present on ARM platforms with scp firmware. As such, exploitation is non-trivial and environment-specific.

Affected upstream versions: 4.4
Fixed upstream versions: 0, 4.19.256, 5.10.137, 5.15.61, 5.18.18, 5.19.2, 5.4.211, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 5aa558232edc30468d1f35108826dd5b3ffe978f
CVE-2022-50088: kernel: mm/damon/reclaim: fix potential memory leak in damon_reclaim_init()
Component: kernel
Severity: Moderate
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

mm/damon/reclaim: fix potential memory leak in damon_reclaim_init()

damon_reclaim_init() allocates a memory chunk for ctx with
damon_new_ctx().  When damon_select_ops() fails, ctx is not released,
which will lead to a memory leak.

We should release the ctx with damon_destroy_ctx() when damon_select_ops()
fails to fix the memory leak.


Affected upstream versions: 5.18
Fixed upstream versions: 0, 5.18.18, 5.19.2, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 9d3e9e1e0856f4c905bbb870f16f42ae72477071
CVE-2022-50092: kernel: dm thin: fix use-after-free crash in dm_sm_register_threshold_callback
Component: kernel
Severity: Moderate
CWE: CWE-763 (Release of Invalid Pointer or Reference)
CVSS v3: 6 (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

dm thin: fix use-after-free crash in dm_sm_register_threshold_callback

Fault inject on pool metadata device reports:
  BUG: KASAN: use-after-free in dm_pool_register_metadata_threshold+0x40/0x80
  Read of size 8 at addr ffff8881b9d50068 by task dmsetup/950

  CPU: 7 PID: 950 Comm: dmsetup Tainted: G        W         5.19.0-rc6 #1
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014
  Call Trace:
   <TASK>
   dump_stack_lvl+0x34/0x44
   print_address_description.constprop.0.cold+0xeb/0x3f4
   kasan_report.cold+0xe6/0x147
   dm_pool_register_metadata_threshold+0x40/0x80
   pool_ctr+0xa0a/0x1150
   dm_table_add_target+0x2c8/0x640
   table_load+0x1fd/0x430
   ctl_ioctl+0x2c4/0x5a0
   dm_ctl_ioctl+0xa/0x10
   __x64_sys_ioctl+0xb3/0xd0
   do_syscall_64+0x35/0x80
   entry_SYSCALL_64_after_hwframe+0x46/0xb0

This can be easily reproduced using:
  echo offline > /sys/block/sda/device/state
  dd if=/dev/zero of=/dev/mapper/thin bs=4k count=10
  dmsetup load pool --table "0 20971520 thin-pool /dev/sda /dev/sdb 128 0 0"

If a metadata commit fails, the transaction will be aborted and the
metadata space maps will be destroyed. If a DM table reload then
happens for this failed thin-pool, a use-after-free will occur in
dm_sm_register_threshold_callback (called from
dm_pool_register_metadata_threshold).

Fix this by in dm_pool_register_metadata_threshold() by returning the
-EINVAL error if the thin-pool is in fail mode. Also fail pool_ctr()
with a new error message: "Error registering metadata threshold".


Affected upstream versions: 3.10
Fixed upstream versions: 0, 5.10.137, 5.15.61, 5.18.18, 5.19.2, 5.4.211, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 05cef0999b3208b5a6ede1bfac855139e4de55ef