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

block: release rq qos structures for queue without disk

blkcg_init_queue() may add rq qos structures to request queue, previously
blk_cleanup_queue() calls rq_qos_exit() to release them, but commit
8e141f9eb803 ("block: drain file system I/O on del_gendisk")
moves rq_qos_exit() into del_gendisk(), so memory leak is caused
because queues may not have disk, such as un-present scsi luns, nvme
admin queue, ...

Fixes the issue by adding rq_qos_exit() to blk_cleanup_queue() back.

BTW, v5.18 won't need this patch any more since we move
blkcg_init_queue()/blkcg_exit_queue() into disk allocation/release
handler, and patches have been in for-5.18/block.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/60c2c8e2ef3a3ec79de8cbc80a06ca0c21df8c29; https://git.kernel.org/stable/c/d4ad8736ac982111bb0be8306bf19c8207f6600e; https://git.kernel.org/stable/c/daaca3522a8e67c46e39ef09c1d542e866f85f3b
CVE: CVE-2022-48847
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

watch_queue: Fix filter limit check

In watch_queue_set_filter(), there are a couple of places where we check
that the filter type value does not exceed what the type_filter bitmap
can hold.  One place calculates the number of bits by:

   if (tf[i].type >= sizeof(wfilter->type_filter) * 8)

which is fine, but the second does:

   if (tf[i].type >= sizeof(wfilter->type_filter) * BITS_PER_LONG)

which is not.  This can lead to a couple of out-of-bounds writes due to
a too-large type:

 (1) __set_bit() on wfilter->type_filter
 (2) Writing more elements in wfilter->filters[] than we allocated.

Fix this by just using the proper WATCH_TYPE__NR instead, which is the
number of types we actually know about.

The bug may cause an oops looking something like:

  BUG: KASAN: slab-out-of-bounds in watch_queue_set_filter+0x659/0x740
  Write of size 4 at addr ffff88800d2c66bc by task watch_queue_oob/611
  ...
  Call Trace:
   <TASK>
   dump_stack_lvl+0x45/0x59
   print_address_description.constprop.0+0x1f/0x150
   ...
   kasan_report.cold+0x7f/0x11b
   ...
   watch_queue_set_filter+0x659/0x740
   ...
   __x64_sys_ioctl+0x127/0x190
   do_syscall_64+0x43/0x90
   entry_SYSCALL_64_after_hwframe+0x44/0xae

  Allocated by task 611:
   kasan_save_stack+0x1e/0x40
   __kasan_kmalloc+0x81/0xa0
   watch_queue_set_filter+0x23a/0x740
   __x64_sys_ioctl+0x127/0x190
   do_syscall_64+0x43/0x90
   entry_SYSCALL_64_after_hwframe+0x44/0xae

  The buggy address belongs to the object at ffff88800d2c66a0
   which belongs to the cache kmalloc-32 of size 32
  The buggy address is located 28 bytes inside of
   32-byte region [ffff88800d2c66a0, ffff88800d2c66c0)
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/1b09f28f70a5046acd64138075ae3f095238b045; https://git.kernel.org/stable/c/648895da69ced90ca770fd941c3d9479a9d72c16; https://git.kernel.org/stable/c/b36588ebbcef74583824c08352e75838d6fb4ff2
CVE: CVE-2022-48848
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

tracing/osnoise: Do not unregister events twice

Nicolas reported that using:

 # trace-cmd record -e all -M 10 -p osnoise --poll

Resulted in the following kernel warning:

 ------------[ cut here ]------------
 WARNING: CPU: 0 PID: 1217 at kernel/tracepoint.c:404 tracepoint_probe_unregister+0x280/0x370
 [...]
 CPU: 0 PID: 1217 Comm: trace-cmd Not tainted 5.17.0-rc6-next-20220307-nico+ #19
 RIP: 0010:tracepoint_probe_unregister+0x280/0x370
 [...]
 CR2: 00007ff919b29497 CR3:[PII_REDACTED]da4005 CR4:[PII_REDACTED]170ef0
 Call Trace:
  <TASK>
  osnoise_workload_stop+0x36/0x90
  tracing_set_tracer+0x108/0x260
  tracing_set_trace_write+0x94/0xd0
  ? __check_object_size.part.0+0x10a/0x150
  ? selinux_file_permission+0x104/0x150
  vfs_write+0xb5/0x290
  ksys_write+0x5f/0xe0
  do_syscall_64+0x3b/0x90
  entry_SYSCALL_64_after_hwframe+0x44/0xae
 RIP: 0033:0x7ff919a18127
 [...]
 ---[ end trace [PII_REDACTED] ]---

The warning complains about an attempt to unregister an
unregistered tracepoint.

This happens on trace-cmd because it first stops tracing, and
then switches the tracer to nop. Which is equivalent to:

  # cd /sys/kernel/tracing/
  # echo osnoise > current_tracer
  # echo 0 > tracing_on
  # echo nop > current_tracer

The osnoise tracer stops the workload when no trace instance
is actually collecting data. This can be caused both by
disabling tracing or disabling the tracer itself.

To avoid unregistering events twice, use the existing
trace_osnoise_callback_enabled variable to check if the events
(and the workload) are actually active before trying to
deactivate them.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/4e10787d18379d9b296290c2288097feddef16d4; https://git.kernel.org/stable/c/f0cfe17bcc1dd2f0872966b554a148e888833ee9; https://git.kernel.org/stable/c/4e10787d18379d9b296290c2288097feddef16d4
CVE: CVE-2022-48849
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: bypass tiling flag check in virtual display case (v2)

vkms leverages common amdgpu framebuffer creation, and
also as it does not support FB modifier, there is no need
to check tiling flags when initing framebuffer when virtual
display is enabled.

This can fix below calltrace:

amdgpu 0000:00:08.0: GFX9+ requires FB check based on format modifier
WARNING: CPU: 0 PID: 1023 at drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:1150 amdgpu_display_framebuffer_init+0x8e7/0xb40 [amdgpu]

v2: check adev->enable_virtual_display instead as vkms can be
	enabled in bare metal as well.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/cb29021be[PII_REDACTED]8f75d6311a7c35a9379b2; https://git.kernel.org/stable/c/e2b993302f40c4eb714ecf896dd9e1c5be7d4cd7; https://git.kernel.org/stable/c/cb29021be[PII_REDACTED]8f75d6311a7c35a9379b2
CVE: CVE-2022-48850
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net-sysfs: add check for netdevice being present to speed_show

When bringing down the netdevice or system shutdown, a panic can be
triggered while accessing the sysfs path because the device is already
removed.

    [  755.549084] mlx5_core 0000:12:00.1: Shutdown was called
    [  756.404455] mlx5_core 0000:12:00.0: Shutdown was called
    ...
    [  757.937260] BUG: unable to handle kernel NULL pointer dereference at           (null)
    [  758.031397] IP: [<ffffffff8ee11acb>] dma_pool_alloc+0x1ab/0x280

    crash> bt
    ...
    PID: 12649  TASK: ffff8924108f2100  CPU: 1   COMMAND: "amsd"
    ...
     #9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778
        [exception RIP: dma_pool_alloc+0x1ab]
        RIP: ffffffff8ee11acb  RSP: ffff89240e1a3968  RFLAGS: 00010046
        RAX: [PII_REDACTED]  RBX: ffff89243d874100  RCX: [PII_REDACTED]
        RDX: [PII_REDACTED]  RSI: [PII_REDACTED]  RDI: ffff89243d874090
        RBP: ffff89240e1a39c0   R8:[PII_REDACTED]01f080   R9: ffff8905ffc03c00
        R10: ffffffffc04680d4  R11: ffffffff8edde9fd  R12:[PII_REDACTED]0080d0
        R13: ffff89243d874090  R14: ffff89243d874080  R15: [PII_REDACTED]
        ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
    #10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core]
    #11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core]
    #12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core]
    #13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core]
    #14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core]
    #15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core]
    #16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core]
    #17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46
    #18 [ffff89240e1a3d48] speed_show at ffffffff8f277208
    #19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3
    #20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf
    #21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596
    #22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10
    #23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5
    #24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff
    #25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f
    #26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92

    crash> net_device.state ffff89443b0c0000
      state = 0x5  (__LINK_STATE_START| __LINK_STATE_NOCARRIER)

To prevent this scenario, we also make sure that the netdevice is present.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/081369ad088a[PII_REDACTED]3b8a5f7e967a125aad; https://git.kernel.org/stable/c/3a79f380b3e10edf6caa9aac90163a5d7a282204; https://git.kernel.org/stable/c/4224cfd7fb6523f7a9d1c8bb91bb5df1e38eb624
CVE: CVE-2022-48851
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

staging: gdm724x: fix use after free in gdm_lte_rx()

The netif_rx_ni() function frees the skb so we can't dereference it to
save the skb->len.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/1fb9dd3787495b4deb0efe66c58306b65691a48f; https://git.kernel.org/stable/c/403e3afe241b62401de1f8629c9c6b9b3d69dbff; https://git.kernel.org/stable/c/48ecdf3e29a6e514e[PII_REDACTED]c7dfc6c4ac169
CVE: CVE-2022-48852
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/vc4: hdmi: Unregister codec device on unbind

On bind we will register the HDMI codec device but we don't unregister
it on unbind, leading to a device leakage. Unregister our device at
unbind.
CVSS Score: 3.3 (LOW)
References: https://git.kernel.org/stable/c/1ed68d776246f167aee9cd79f63f089c40a5e2a3; https://git.kernel.org/stable/c/e40945ab7c7f966d0c37b7bd7b0596497dfe228d; https://git.kernel.org/stable/c/ee22082c3e2f230028afa0e22aa8773b1de3c919
CVE: CVE-2022-48853
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

swiotlb: fix info leak with DMA_FROM_DEVICE

The problem I'm addressing was discovered by the LTP test covering
cve-2[PII_REDACTED].

A short description of what happens follows:
1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO
   interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV
   and a corresponding dxferp. The peculiar thing about this is that TUR
   is not reading from the device.
2) In sg_start_req() the invocation of blk_rq_map_user() effectively
   bounces the user-space buffer. As if the device was to transfer into
   it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in
   sg_build_indirect()") we make sure this first bounce buffer is
   allocated with GFP_ZERO.
3) For the rest of the story we keep ignoring that we have a TUR, so the
   device won't touch the buffer we prepare as if the we had a
   DMA_FROM_DEVICE type of situation. My setup uses a virtio-scsi device
   and the  buffer allocated by SG is mapped by the function
   virtqueue_add_split() which uses DMA_FROM_DEVICE for the "in" sgs (here
   scatter-gather and not scsi generics). This mapping involves bouncing
   via the swiotlb (we need swiotlb to do virtio in protected guest like
   s390 Secure Execution, or AMD SEV).
4) When the SCSI TUR is done, we first copy back the content of the second
   (that is swiotlb) bounce buffer (which most likely contains some
   previous IO data), to the first bounce buffer, which contains all
   zeros.  Then we copy back the content of the first bounce buffer to
   the user-space buffer.
5) The test case detects that the buffer, which it zero-initialized,
  ain't all zeros and fails.

One can argue that this is an swiotlb problem, because without swiotlb
we leak all zeros, and the swiotlb should be transparent in a sense that
it does not affect the outcome (if all other participants are well
behaved).

Copying the content of the original buffer into the swiotlb buffer is
the only way I can think of to make swiotlb transparent in such
scenarios. So let's do just that if in doubt, but allow the driver
to tell us that the whole mapped buffer is going to be overwritten,
in which case we can preserve the old behavior and avoid the performance
impact of the extra bounce.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/06cb238b0f7ac1669cb06390704c61794724c191; https://git.kernel.org/stable/c/7007c894631cf43041dcfa0da7142bbaa7eb673c; https://git.kernel.org/stable/c/901c7280ca0d5e2b4a8929fbe0bfb007ac2a6544
CVE: CVE-2022-48854
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: arc_emac: Fix use after free in arc_mdio_probe()

If bus->state is equal to MDIOBUS_ALLOCATED, mdiobus_free(bus) will free
the "bus". But bus->name is still used in the next line, which will lead
to a use after free.

We can fix it by putting the name in a local variable and make the
bus->name point to the rodata section "name",then use the name in the
error message without referring to bus to avoid the uaf.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/84c831803785c2c3bec5c28c0e8a0b72f6b41d4d; https://git.kernel.org/stable/c/bc0e610a6eb0d46e4123fafdbe5e6141d9fff3be; https://git.kernel.org/stable/c/84c831803785c2c3bec5c28c0e8a0b72f6b41d4d
CVE: CVE-2022-48856
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

gianfar: ethtool: Fix refcount leak in gfar_get_ts_info

The of_find_compatible_node() function returns a node pointer with
refcount incremented, We should use of_node_put() on it when done
Add the missing of_node_put() to release the refcount.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/0e1b9a2078e07fb1e6e91bf8badfd89ecab1e848; https://git.kernel.org/stable/c/21044e679ed535345042d2023f7df0ca8e897e2a; https://git.kernel.org/stable/c/2ac5b58e645c66932438bb021cb5b52097ce70b0
CVE: CVE-2022-48857
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

NFC: port100: fix use-after-free in port100_send_complete

Syzbot reported UAF in port100_send_complete(). The root case is in
missing usb_kill_urb() calls on error handling path of ->probe function.

port100_send_complete() accesses devm allocated memory which will be
freed on probe failure. We should kill this urbs before returning an
error from probe function to prevent reported use-after-free

Fail log:

BUG: KASAN: use-after-free in port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935
Read of size 1 at addr ffff88801bb59540 by task ksoftirqd/2/26
...
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
 print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255
 __kasan_report mm/kasan/report.c:442 [inline]
 kasan_report.cold+0x83/0xdf mm/kasan/report.c:459
 port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935
 __usb_hcd_giveback_urb+0x2b0/0x5c0 drivers/usb/core/hcd.c:1670

...

Allocated by task 1255:
 kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
 kasan_set_track mm/kasan/common.c:45 [inline]
 set_alloc_info mm/kasan/common.c:436 [inline]
 ____kasan_kmalloc mm/kasan/common.c:515 [inline]
 ____kasan_kmalloc mm/kasan/common.c:474 [inline]
 __kasan_kmalloc+0xa6/0xd0 mm/kasan/common.c:524
 alloc_dr drivers/base/devres.c:116 [inline]
 devm_kmalloc+0x96/0x1d0 drivers/base/devres.c:823
 devm_kzalloc include/linux/device.h:209 [inline]
 port100_probe+0x8a/0x1320 drivers/nfc/port100.c:1502

Freed by task 1255:
 kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
 kasan_set_track+0x21/0x30 mm/kasan/common.c:45
 kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370
 ____kasan_slab_free mm/kasan/common.c:366 [inline]
 ____kasan_slab_free+0xff/0x140 mm/kasan/common.c:328
 kasan_slab_free include/linux/kasan.h:236 [inline]
 __cache_free mm/slab.c:3437 [inline]
 kfree+0xf8/0x2b0 mm/slab.c:3794
 release_nodes+0x112/0x1a0 drivers/base/devres.c:501
 devres_release_all+0x114/0x190 drivers/base/devres.c:530
 really_probe+0x626/0xcc0 drivers/base/dd.c:670
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0e721b8f2ee5e11376dd55363f9ccb539d754b8a; https://git.kernel.org/stable/c/205c4ec78e71cbf561794e6043da80e7bae6790f; https://git.kernel.org/stable/c/2b1c85f56512d49e43bc53741fce2f508cd90029
CVE: CVE-2022-48858
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: Fix a race on command flush flow

Fix a refcount use after free warning due to a race on command entry.
Such race occurs when one of the commands releases its last refcount and
frees its index and entry while another process running command flush
flow takes refcount to this command entry. The process which handles
commands flush may see this command as needed to be flushed if the other
process released its refcount but didn't release the index yet. Fix it
by adding the needed spin lock.

It fixes the following warning trace:

refcount_t: addition on 0; use-after-free.
WARNING: CPU: 11 PID: 540311 at lib/refcount.c:25 refcount_warn_saturate+0x80/0xe0
...
RIP: 0010:refcount_warn_saturate+0x80/0xe0
...
Call Trace:
 <TASK>
 mlx5_cmd_trigger_completions+0x293/0x340 [mlx5_core]
 mlx5_cmd_flush+0x3a/0xf0 [mlx5_core]
 enter_error_state+0x44/0x80 [mlx5_core]
 mlx5_fw_fatal_reporter_err_work+0x37/0xe0 [mlx5_core]
 process_one_work+0x1be/0x390
 worker_thread+0x4d/0x3d0
 ? rescuer_thread+0x350/0x350
 kthread+0x141/0x160
 ? set_kthread_struct+0x40/0x40
 ret_from_fork+0x1f/0x30
 </TASK>
CVSS Score: 7.0 (HIGH)
CWE: CWE-362, CWE-416
References: https://git.kernel.org/stable/c/0401bfb27a91d7bdd74b1635c1aae57cbb128da6; https://git.kernel.org/stable/c/063bd[PII_REDACTED]50803d8736a9bb7c8db67d42d; https://git.kernel.org/stable/c/1a4017926eeea56c7540cc41b42106746ee8a0ee
CVE: CVE-2022-48859
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: marvell: prestera: Add missing of_node_put() in prestera_switch_set_base_mac_addr

This node pointer is returned by of_find_compatible_node() with
refcount incremented. Calling of_node_put() to aovid the refcount leak.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/4cc66bf17220ff9631f9fa99b02a872e0ad5a08b; https://git.kernel.org/stable/c/b7c2fd1d[PII_REDACTED]9adfb8dd2938fe4b65df7; https://git.kernel.org/stable/c/c9ffa3e2bc451816ce0295e40063514fabf2bd36
CVE: CVE-2022-48860
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

ethernet: Fix error handling in xemaclite_of_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. As the remove function do.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/1852854ee349881efb78ccdbbb[PII_REDACTED]02e4; https://git.kernel.org/stable/c/5e7c402892e189a7bc152b125e72261154aa585d; https://git.kernel.org/stable/c/669172ce976608b25a2f76f3c65d47f042d125c9
CVE: CVE-2022-48861
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

vdpa: fix use-after-free on vp_vdpa_remove

When vp_vdpa driver is unbind, vp_vdpa is freed in vdpa_unregister_device
and then vp_vdpa->mdev.pci_dev is dereferenced in vp_modern_remove,
triggering use-after-free.

Call Trace of unbinding driver free vp_vdpa :
do_syscall_64
  vfs_write
    kernfs_fop_write_iter
      device_release_driver_internal
        pci_device_remove
          vp_vdpa_remove
            vdpa_unregister_device
              kobject_release
                device_release
                  kfree

Call Trace of dereference vp_vdpa->mdev.pci_dev:
vp_modern_remove
  pci_release_selected_regions
    pci_release_region
      pci_resource_len
        pci_resource_end
          (dev)->resource[(bar)].end
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-416
References: https://git.kernel.org/stable/c/4b1743bc715a3691a63ac21b349079b07bf1b19e; https://git.kernel.org/stable/c/dc54ba9932aeaaa1a21fe214af1f446593a78274; https://git.kernel.org/stable/c/eb057b44dbe35ae[PII_REDACTED]a92f51de8f9184
CVE: CVE-2022-48862
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

vhost: fix hung thread due to erroneous iotlb entries

In vhost_iotlb_add_range_ctx(), range size can overflow to 0 when
start is 0 and last is ULONG_MAX. One instance where it can happen
is when userspace sends an IOTLB message with iova=size=uaddr=0
(vhost_process_iotlb_msg). So, an entry with size = 0, start = 0,
last = ULONG_MAX ends up in the iotlb. Next time a packet is sent,
iotlb_access_ok() loops indefinitely due to that erroneous entry.

	Call Trace:
	 <TASK>
	 iotlb_access_ok+0x21b/0x3e0 drivers/vhost/vhost.c:1340
	 vq_meta_prefetch+0xbc/0x280 drivers/vhost/vhost.c:1366
	 vhost_transport_do_send_pkt+0xe0/0xfd0 drivers/vhost/vsock.c:104
	 vhost_worker+0x23d/0x3d0 drivers/vhost/vhost.c:372
	 kthread+0x2e9/0x3a0 kernel/kthread.c:377
	 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
	 </TASK>

Reported by syzbot at:
	https://syzkaller.appspot.com/bug?extid=0abd373e2e50d704db87

To fix this, do two things:

1. Return -EINVAL in vhost_chr_write_iter() when userspace asks to map
   a range with size 0.
2. Fix vhost_iotlb_add_range_ctx() to handle the range [0, ULONG_MAX]
   by splitting it into two entries.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-835
References: https://git.kernel.org/stable/c/d9a747e6b6561280bf1791bb24c5e9e082193dad; https://git.kernel.org/stable/c/e2ae38cf3d91837a493cb2093c87700ff3cbe667; https://git.kernel.org/stable/c/f8d88e86e90ea1002226d7ac2430152bfea003d1
CVE: CVE-2022-48863
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

mISDN: Fix memory leak in dsp_pipeline_build()

dsp_pipeline_build() allocates dup pointer by kstrdup(cfg),
but then it updates dup variable by strsep(&dup, "|").
As a result when it calls kfree(dup), the dup variable contains NULL.

Found by Linux Driver Verification project (linuxtesting.org) with SVACE.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/640445d6fc059d4514ffea79eb4196299e0e2d0f; https://git.kernel.org/stable/c/7777b1f795af1bb43867375d8a776080111aae1b; https://git.kernel.org/stable/c/a3d5fcc6cf2ecbba5a[PII_REDACTED]70aa285a24cb
CVE: CVE-2022-48864
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

vdpa/mlx5: add validation for VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command

When control vq receives a VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command
request from the driver, presently there is no validation against the
number of queue pairs to configure, or even if multiqueue had been
negotiated or not is unverified. This may lead to kernel panic due to
uninitialized resource for the queues were there any bogus request
sent down by untrusted driver. Tie up the loose ends there.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/9f6effca75626c7a7c7620dabcb1a254ca530230; https://git.kernel.org/stable/c/e7e118416465f2ba8b55007e5b789823e101421e; https://git.kernel.org/stable/c/ed0f849fc3a63ed2ddf5e72cdb1de3bdbbb0f8eb