Ubuntu 22.04 LTS : Linux kernel (OEM) vulnerabilities (USN-6688-1)

#%NASL_MIN_LEVEL 80900
##
# (C) Tenable, Inc.
#
# The descriptive text and package checks in this plugin were
# extracted from Ubuntu Security Notice USN-6688-1. The text
# itself is copyright (C) Canonical, Inc. See
# <https://ubuntu.com/security/notices>. Ubuntu(R) is a registered
# trademark of Canonical, Inc.
##

include('compat.inc');

if (description)
{
  script_id(191796);
  script_version("1.3");
  script_set_attribute(attribute:"plugin_modification_date", value:"2024/04/18");

  script_cve_id(
    "CVE-2023-5633",
    "CVE-2023-6610",
    "CVE-2023-46838",
    "CVE-2023-50431",
    "CVE-2023-52436",
    "CVE-2023-52438",
    "CVE-2023-52439",
    "CVE-2023-52443",
    "CVE-2023-52444",
    "CVE-2023-52445",
    "CVE-2023-52447",
    "CVE-2023-52448",
    "CVE-2023-52449",
    "CVE-2023-52451",
    "CVE-2023-52454",
    "CVE-2023-52456",
    "CVE-2023-52457",
    "CVE-2023-52458",
    "CVE-2023-52462",
    "CVE-2023-52463",
    "CVE-2023-52464",
    "CVE-2023-52467",
    "CVE-2023-52469",
    "CVE-2023-52470",
    "CVE-2023-52583",
    "CVE-2023-52584",
    "CVE-2023-52587",
    "CVE-2023-52588",
    "CVE-2023-52589",
    "CVE-2023-52593",
    "CVE-2023-52594",
    "CVE-2023-52595",
    "CVE-2023-52597",
    "CVE-2023-52598",
    "CVE-2023-52599",
    "CVE-2023-52600",
    "CVE-2023-52601",
    "CVE-2023-52602",
    "CVE-2023-52603",
    "CVE-2023-52604",
    "CVE-2023-52605",
    "CVE-2023-52606",
    "CVE-2023-52607",
    "CVE-2024-0340",
    "CVE-2024-1085",
    "CVE-2024-1086",
    "CVE-2024-23849",
    "CVE-2024-24860",
    "CVE-2024-26581",
    "CVE-2024-26588",
    "CVE-2024-26589",
    "CVE-2024-26591",
    "CVE-2024-26592",
    "CVE-2024-26594",
    "CVE-2024-26597",
    "CVE-2024-26598",
    "CVE-2024-26599",
    "CVE-2024-26600",
    "CVE-2024-26601",
    "CVE-2024-26624",
    "CVE-2024-26625",
    "CVE-2024-26627",
    "CVE-2024-26628"
  );
  script_xref(name:"USN", value:"6688-1");

  script_name(english:"Ubuntu 22.04 LTS : Linux kernel (OEM) vulnerabilities (USN-6688-1)");

  script_set_attribute(attribute:"synopsis", value:
"The remote Ubuntu host is missing one or more security updates.");
  script_set_attribute(attribute:"description", value:
"The remote Ubuntu 22.04 LTS host has a package installed that is affected by multiple vulnerabilities as referenced in
the USN-6688-1 advisory.

  - Transmit requests in Xen's virtual network protocol can consist of multiple parts. While not really
    useful, except for the initial part any of them may be of zero length, i.e. carry no data at all. Besides
    a certain initial portion of the to be transferred data, these parts are directly translated into what
    Linux calls SKB fragments. Such converted request parts can, when for a particular SKB they are all of
    length zero, lead to a de-reference of NULL in core networking code. (CVE-2023-46838)

  - sec_attest_info in drivers/accel/habanalabs/common/habanalabs_ioctl.c in the Linux kernel through 6.6.5
    allows an information leak to user space because info->pad0 is not initialized. (CVE-2023-50431)

  - In the Linux kernel, the following vulnerability has been resolved: f2fs: explicitly null-terminate the
    xattr list When setting an xattr, explicitly null-terminate the xattr list. This eliminates the fragile
    assumption that the unused xattr space is always zeroed. (CVE-2023-52436)

  - In the Linux kernel, the following vulnerability has been resolved: binder: fix use-after-free in
    shinker's callback The mmap read lock is used during the shrinker's callback, which means that using
    alloc->vma pointer isn't safe as it can race with munmap(). As of commit dd2283f2605e (mm: mmap: zap
    pages with read mmap_sem in munmap) the mmap lock is downgraded after the vma has been isolated. I was
    able to reproduce this issue by manually adding some delays and triggering page reclaiming through the
    shrinker's debug sysfs. The following KASAN report confirms the UAF:
    ================================================================== BUG: KASAN: slab-use-after-free in
    zap_page_range_single+0x470/0x4b8 Read of size 8 at addr ffff356ed50e50f0 by task bash/478 CPU: 1 PID: 478
    Comm: bash Not tainted 6.6.0-rc5-00055-g1c8b86a3799f-dirty #70 Hardware name: linux,dummy-virt (DT) Call
    trace: zap_page_range_single+0x470/0x4b8 binder_alloc_free_page+0x608/0xadc
    __list_lru_walk_one+0x130/0x3b0 list_lru_walk_node+0xc4/0x22c binder_shrink_scan+0x108/0x1dc
    shrinker_debugfs_scan_write+0x2b4/0x500 full_proxy_write+0xd4/0x140 vfs_write+0x1ac/0x758
    ksys_write+0xf0/0x1dc __arm64_sys_write+0x6c/0x9c Allocated by task 492: kmem_cache_alloc+0x130/0x368
    vm_area_alloc+0x2c/0x190 mmap_region+0x258/0x18bc do_mmap+0x694/0xa60 vm_mmap_pgoff+0x170/0x29c
    ksys_mmap_pgoff+0x290/0x3a0 __arm64_sys_mmap+0xcc/0x144 Freed by task 491: kmem_cache_free+0x17c/0x3c8
    vm_area_free_rcu_cb+0x74/0x98 rcu_core+0xa38/0x26d4 rcu_core_si+0x10/0x1c __do_softirq+0x2fc/0xd24 Last
    potentially related work creation: __call_rcu_common.constprop.0+0x6c/0xba0 call_rcu+0x10/0x1c
    vm_area_free+0x18/0x24 remove_vma+0xe4/0x118 do_vmi_align_munmap.isra.0+0x718/0xb5c
    do_vmi_munmap+0xdc/0x1fc __vm_munmap+0x10c/0x278 __arm64_sys_munmap+0x58/0x7c Fix this issue by performing
    instead a vma_lookup() which will fail to find the vma that was isolated before the mmap lock downgrade.
    Note that this option has better performance than upgrading to a mmap write lock which would increase
    contention. Plus, mmap_write_trylock() has been recently removed anyway. (CVE-2023-52438)

  - In the Linux kernel, the following vulnerability has been resolved: uio: Fix use-after-free in uio_open
    core-1 core-2 ------------------------------------------------------- uio_unregister_device uio_open idev
    = idr_find() device_unregister(&idev->dev) put_device(&idev->dev) uio_device_release
    get_device(&idev->dev) kfree(idev) uio_free_minor(minor) uio_release put_device(&idev->dev) kfree(idev)
    ------------------------------------------------------- In the core-1 uio_unregister_device(), the
    device_unregister will kfree idev when the idev->dev kobject ref is 1. But after core-1 device_unregister,
    put_device and before doing kfree, the core-2 may get_device. Then: 1. After core-1 kfree idev, the core-2
    will do use-after-free for idev. 2. When core-2 do uio_release and put_device, the idev will be double
    freed. To address this issue, we can get idev atomic & inc idev reference with minor_lock.
    (CVE-2023-52439)

  - In the Linux kernel, the following vulnerability has been resolved: apparmor: avoid crash when parsed
    profile name is empty When processing a packed profile in unpack_profile() described like profile
    :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...} a string :samba-dcerpcd is unpacked as
    a fully-qualified name and then passed to aa_splitn_fqname(). aa_splitn_fqname() treats :samba-dcerpcd
    as only containing a namespace. Thus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Later
    aa_alloc_profile() crashes as the new profile name is NULL now. general protection fault, probably for
    non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range
    [0x0000000000000000-0x0000000000000007] CPU: 6 PID: 1657 Comm: apparmor_parser Not tainted 6.7.0-rc2-dirty
    #16 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
    rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 RIP: 0010:strlen+0x1e/0xa0 Call Trace: <TASK> ?
    strlen+0x1e/0xa0 aa_policy_init+0x1bb/0x230 aa_alloc_profile+0xb1/0x480 unpack_profile+0x3bc/0x4960
    aa_unpack+0x309/0x15e0 aa_replace_profiles+0x213/0x33c0 policy_update+0x261/0x370
    profile_replace+0x20e/0x2a0 vfs_write+0x2af/0xe00 ksys_write+0x126/0x250 do_syscall_64+0x46/0xf0
    entry_SYSCALL_64_after_hwframe+0x6e/0x76 </TASK> ---[ end trace 0000000000000000 ]--- RIP:
    0010:strlen+0x1e/0xa0 It seems such behaviour of aa_splitn_fqname() is expected and checked in other
    places where it is called (e.g. aa_remove_profiles). Well, there is an explicit comment a ns name without
    a following profile is allowed inside. AFAICS, nothing can prevent unpacked name to be in form like
    :samba-dcerpcd - it is passed from userspace. Deny the whole profile set replacement in such case and
    inform user with EPROTO and an explaining message. Found by Linux Verification Center (linuxtesting.org).
    (CVE-2023-52443)

  - In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid dirent corruption
    As Al reported in link[1]: f2fs_rename() ... if (old_dir != new_dir && !whiteout) f2fs_set_link(old_inode,
    old_dir_entry, old_dir_page, new_dir); else f2fs_put_page(old_dir_page, 0); You want correct inumber in
    the .. link. And cross-directory rename does move the source to new parent, even if you'd been asked to
    leave a whiteout in the old place. [1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/ With
    below testcase, it may cause dirent corruption, due to it missed to call f2fs_set_link() to update ..
    link to new directory. - mkdir -p dir/foo - renameat2 -w dir/foo bar [ASSERT] (__chk_dots_dentries:1421)
    --> Bad inode number[0x4] for '..', parent parent ino is [0x3] [FSCK] other corrupted bugs [Fail]
    (CVE-2023-52444)

  - In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix use after free on
    context disconnection Upon module load, a kthread is created targeting the pvr2_context_thread_func
    function, which may call pvr2_context_destroy and thus call kfree() on the context object. However, that
    might happen before the usb hub_event handler is able to notify the driver. This patch adds a sanity check
    before the invalid read reported by syzbot, within the context disconnection call stack. (CVE-2023-52445)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Defer the free of inner map when
    necessary When updating or deleting an inner map in map array or map htab, the map may still be accessed
    by non-sleepable program or sleepable program. However bpf_map_fd_put_ptr() decreases the ref-counter of
    the inner map directly through bpf_map_put(), if the ref-counter is the last one (which is true for most
    cases), the inner map will be freed by ops->map_free() in a kworker. But for now, most .map_free()
    callbacks don't use synchronize_rcu() or its variants to wait for the elapse of a RCU grace period, so
    after the invocation of ops->map_free completes, the bpf program which is accessing the inner map may
    incur use-after-free problem. Fix the free of inner map by invoking bpf_map_free_deferred() after both one
    RCU grace period and one tasks trace RCU grace period if the inner map has been removed from the outer map
    before. The deferment is accomplished by using call_rcu() or call_rcu_tasks_trace() when releasing the
    last ref-counter of bpf map. The newly-added rcu_head field in bpf_map shares the same storage space with
    work field to reduce the size of bpf_map. (CVE-2023-52447)

  - In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix kernel NULL pointer
    dereference in gfs2_rgrp_dump Syzkaller has reported a NULL pointer dereference when accessing rgd->rd_rgl
    in gfs2_rgrp_dump(). This can happen when creating rgd->rd_gl fails in read_rindex_entry(). Add a NULL
    pointer check in gfs2_rgrp_dump() to prevent that. (CVE-2023-52448)

  - In the Linux kernel, the following vulnerability has been resolved: mtd: Fix gluebi NULL pointer
    dereference caused by ftl notifier If both ftl.ko and gluebi.ko are loaded, the notifier of ftl triggers
    NULL pointer dereference when trying to access gluebi->desc' in gluebi_read(). ubi_gluebi_init
    ubi_register_volume_notifier ubi_enumerate_volumes ubi_notify_all gluebi_notify nb->notifier_call()
    gluebi_create mtd_device_register mtd_device_parse_register add_mtd_device blktrans_notify_add not->add()
    ftl_add_mtd tr->add_mtd() scan_header mtd_read mtd_read_oob mtd_read_oob_std gluebi_read mtd->read()
    gluebi->desc - NULL Detailed reproduction information available at the Link [1], In the normal case,
    obtain gluebi->desc in the gluebi_get_device(), and access gluebi->desc in the gluebi_read(). However,
    gluebi_get_device() is not executed in advance in the ftl_add_mtd() process, which leads to NULL pointer
    dereference. The solution for the gluebi module is to run jffs2 on the UBI volume without considering
    working with ftl or mtdblock [2]. Therefore, this problem can be avoided by preventing gluebi from
    creating the mtdblock device after creating mtd partition of the type MTD_UBIVOLUME. (CVE-2023-52449)

  - In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/memhp: Fix access
    beyond end of drmem array dlpar_memory_remove_by_index() may access beyond the bounds of the drmem lmb
    array when the LMB lookup fails to match an entry with the given DRC index. When the search fails, the
    cursor is left pointing to &drmem_info->lmbs[drmem_info->n_lmbs], which is one element past the last valid
    entry in the array. The debug message at the end of the function then dereferences this pointer:
    pr_debug(Failed to hot-remove memory at %llx\n, lmb->base_addr); This was found by inspection and
    confirmed with KASAN: pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234
    ================================================================== BUG: KASAN: slab-out-of-bounds in
    dlpar_memory+0x298/0x1658 Read of size 8 at addr c000000364e97fd0 by task bash/949
    dump_stack_lvl+0xa4/0xfc (unreliable) print_report+0x214/0x63c kasan_report+0x140/0x2e0
    __asan_load8+0xa8/0xe0 dlpar_memory+0x298/0x1658 handle_dlpar_errorlog+0x130/0x1d0 dlpar_store+0x18c/0x3e0
    kobj_attr_store+0x68/0xa0 sysfs_kf_write+0xc4/0x110 kernfs_fop_write_iter+0x26c/0x390
    vfs_write+0x2d4/0x4e0 ksys_write+0xac/0x1a0 system_call_exception+0x268/0x530
    system_call_vectored_common+0x15c/0x2ec Allocated by task 1: kasan_save_stack+0x48/0x80
    kasan_set_track+0x34/0x50 kasan_save_alloc_info+0x34/0x50 __kasan_kmalloc+0xd0/0x120 __kmalloc+0x8c/0x320
    kmalloc_array.constprop.0+0x48/0x5c drmem_init+0x2a0/0x41c do_one_initcall+0xe0/0x5c0
    kernel_init_freeable+0x4ec/0x5a0 kernel_init+0x30/0x1e0 ret_from_kernel_user_thread+0x14/0x1c The buggy
    address belongs to the object at c000000364e80000 which belongs to the cache kmalloc-128k of size 131072
    The buggy address is located 0 bytes to the right of allocated 98256-byte region [c000000364e80000,
    c000000364e97fd0) ================================================================== pseries-hotplug-mem:
    Failed to hot-remove memory at 0 Log failed lookups with a separate message and dereference the cursor
    only when it points to a valid entry. (CVE-2023-52451)

  - In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix a kernel panic when
    host sends an invalid H2C PDU length If the host sends an H2CData command with an invalid DATAL, the
    kernel may crash in nvmet_tcp_build_pdu_iovec(). Unable to handle kernel NULL pointer dereference at
    virtual address 0000000000000000 lr : nvmet_tcp_io_work+0x6ac/0x718 [nvmet_tcp] Call trace:
    process_one_work+0x174/0x3c8 worker_thread+0x2d0/0x3e8 kthread+0x104/0x110 Fix the bug by raising a fatal
    error if DATAL isn't coherent with the packet size. Also, the PDU length should never exceed the
    MAXH2CDATA parameter which has been communicated to the host in nvmet_tcp_handle_icreq(). (CVE-2023-52454)

  - In the Linux kernel, the following vulnerability has been resolved: serial: imx: fix tx statemachine
    deadlock When using the serial port as RS485 port, the tx statemachine is used to control the RTS pin to
    drive the RS485 transceiver TX_EN pin. When the TTY port is closed in the middle of a transmission (for
    instance during userland application crash), imx_uart_shutdown disables the interface and disables the
    Transmission Complete interrupt. afer that, imx_uart_stop_tx bails on an incomplete transmission, to be
    retriggered by the TC interrupt. This interrupt is disabled and therefore the tx statemachine never
    transitions out of SEND. The statemachine is in deadlock now, and the TX_EN remains low, making the
    interface useless. imx_uart_stop_tx now checks for incomplete transmission AND whether TC interrupts are
    enabled before bailing to be retriggered. This makes sure the state machine handling is reached, and is
    properly set to WAIT_AFTER_SEND. (CVE-2023-52456)

  - In the Linux kernel, the following vulnerability has been resolved: serial: 8250: omap: Don't skip
    resource freeing if pm_runtime_resume_and_get() failed Returning an error code from .remove() makes the
    driver core emit the little helpful error message: remove callback returned a non-zero value. This will be
    ignored. and then remove the device anyhow. So all resources that were not freed are leaked in this case.
    Skipping serial8250_unregister_port() has the potential to keep enough of the UART around to trigger a
    use-after-free. So replace the error return (and with it the little helpful error message) by a more
    useful error message and continue to cleanup. (CVE-2023-52457)

  - In the Linux kernel, the following vulnerability has been resolved: block: add check that partition length
    needs to be aligned with block size Before calling add partition or resize partition, there is no check on
    whether the length is aligned with the logical block size. If the logical block size of the disk is larger
    than 512 bytes, then the partition size maybe not the multiple of the logical block size, and when the
    last sector is read, bio_truncate() will adjust the bio size, resulting in an IO error if the size of the
    read command is smaller than the logical block size.If integrity data is supported, this will also result
    in a null pointer dereference when calling bio_integrity_free. (CVE-2023-52458)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: fix check for attempt to corrupt
    spilled pointer When register is spilled onto a stack as a 1/2/4-byte register, we set
    slot_type[BPF_REG_SIZE - 1] (plus potentially few more below it, depending on actual spill size). So to
    check if some stack slot has spilled register we need to consult slot_type[7], not slot_type[0]. To avoid
    the need to remember and double-check this in the future, just use is_spilled_reg() helper.
    (CVE-2023-52462)

  - In the Linux kernel, the following vulnerability has been resolved: efivarfs: force RO when remounting if
    SetVariable is not supported If SetVariable at runtime is not supported by the firmware we never assign a
    callback for that function. At the same time mount the efivarfs as RO so no one can call that. However, we
    never check the permission flags when someone remounts the filesystem as RW. As a result this leads to a
    crash looking like this: $ mount -o remount,rw /sys/firmware/efi/efivars $ efi-updatevar -f PK.auth PK [
    303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [
    303.280482] Mem abort info: [ 303.280854] ESR = 0x0000000086000004 [ 303.281338] EC = 0x21: IABT (current
    EL), IL = 32 bits [ 303.282016] SET = 0, FnV = 0 [ 303.282414] EA = 0, S1PTW = 0 [ 303.282821] FSC = 0x04:
    level 0 translation fault [ 303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000 [
    303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 303.286076] Internal error:
    Oops: 0000000086000004 [#1] PREEMPT SMP [ 303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core
    crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6 [ 303.288586] CPU: 1 PID: 755 Comm:
    efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1 [ 303.289748] Hardware name: Unknown Unknown
    Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023 [ 303.291150] pstate: 60400005 (nZCv
    daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 303.292123] pc : 0x0 [ 303.292443] lr :
    efivar_set_variable_locked+0x74/0xec [ 303.293156] sp : ffff800008673c10 [ 303.293619] x29:
    ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000 [ 303.294592] x26: 0000000000000800 x25:
    ffff000002467400 x24: 0000000000000027 [ 303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21:
    ffff000002467000 [ 303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000 [
    303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54 [ 303.298495] x14:
    ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4 [ 303.299453] x11: ffff000002af7b01 x10:
    0000000000000003 x9 : 0000000000000002 [ 303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 :
    0000000000a85201 [ 303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc [
    303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000 [ 303.303341] Call trace: [
    303.303679] 0x0 [ 303.303938] efivar_entry_set_get_size+0x98/0x16c [ 303.304585]
    efivarfs_file_write+0xd0/0x1a4 [ 303.305148] vfs_write+0xc4/0x2e4 [ 303.305601] ksys_write+0x70/0x104 [
    303.306073] __arm64_sys_write+0x1c/0x28 [ 303.306622] invoke_syscall+0x48/0x114 [ 303.307156]
    el0_svc_common.constprop.0+0x44/0xec [ 303.307803] do_el0_svc+0x38/0x98 [ 303.308268] el0_svc+0x2c/0x84 [
    303.308702] el0t_64_sync_handler+0xf4/0x120 [ 303.309293] el0t_64_sync+0x190/0x194 [ 303.309794] Code:
    ???????? ???????? ???????? ???????? (????????) [ 303.310612] ---[ end trace 0000000000000000 ]--- Fix this
    by adding a .reconfigure() function to the fs operations which we can use to check the requested flags and
    deny anything that's not RO if the firmware doesn't implement SetVariable at runtime. (CVE-2023-52463)

  - In the Linux kernel, the following vulnerability has been resolved: EDAC/thunderx: Fix possible out-of-
    bounds string access Enabling -Wstringop-overflow globally exposes a warning for a common bug in the usage
    of strncat(): drivers/edac/thunderx_edac.c: In function 'thunderx_ocx_com_threaded_isr':
    drivers/edac/thunderx_edac.c:1136:17: error: 'strncat' specified bound 1024 equals destination size
    [-Werror=stringop-overflow=] 1136 | strncat(msg, other, OCX_MESSAGE_SIZE); |
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... 1145 | strncat(msg, other, OCX_MESSAGE_SIZE); ... 1150 |
    strncat(msg, other, OCX_MESSAGE_SIZE); ... Apparently the author of this driver expected strncat() to
    behave the way that strlcat() does, which uses the size of the destination buffer as its third argument
    rather than the length of the source buffer. The result is that there is no check on the size of the
    allocated buffer. Change it to strlcat(). [ bp: Trim compiler output, fixup commit message. ]
    (CVE-2023-52464)

  - In the Linux kernel, the following vulnerability has been resolved: mfd: syscon: Fix null pointer
    dereference in of_syscon_register() kasprintf() returns a pointer to dynamically allocated memory which
    can be NULL upon failure. (CVE-2023-52467)

  - In the Linux kernel, the following vulnerability has been resolved: drivers/amd/pm: fix a use-after-free
    in kv_parse_power_table When ps allocated by kzalloc equals to NULL, kv_parse_power_table frees
    adev->pm.dpm.ps that allocated before. However, after the control flow goes through the following call
    chains: kv_parse_power_table |-> kv_dpm_init |-> kv_dpm_sw_init |-> kv_dpm_fini The adev->pm.dpm.ps is
    used in the for loop of kv_dpm_fini after its first free in kv_parse_power_table and causes a use-after-
    free bug. (CVE-2023-52469)

  - In the Linux kernel, the following vulnerability has been resolved: drm/radeon: check the alloc_workqueue
    return value in radeon_crtc_init() check the alloc_workqueue return value in radeon_crtc_init() to avoid
    null-ptr-deref. (CVE-2023-52470)

  - In the Linux kernel, the following vulnerability has been resolved: ceph: fix deadlock or deadcode of
    misusing dget() The lock order is incorrect between denty and its parent, we should always make sure that
    the parent get the lock first. But since this deadcode is never used and the parent dir will always be set
    from the callers, let's just remove it. (CVE-2023-52583)

  - In the Linux kernel, the following vulnerability has been resolved: spmi: mediatek: Fix UAF on device
    remove The pmif driver data that contains the clocks is allocated along with spmi_controller. On device
    remove, spmi_controller will be freed first, and then devres , including the clocks, will be cleanup. This
    leads to UAF because putting the clocks will access the clocks in the pmif driver data, which is already
    freed along with spmi_controller. This can be reproduced by enabling DEBUG_TEST_DRIVER_REMOVE and building
    the kernel with KASAN. Fix the UAF issue by using unmanaged clk_bulk_get() and putting the clocks before
    freeing spmi_controller. (CVE-2023-52584)

  - In the Linux kernel, the following vulnerability has been resolved: IB/ipoib: Fix mcast list locking
    Releasing the `priv->lock` while iterating the `priv->multicast_list` in `ipoib_mcast_join_task()` opens a
    window for `ipoib_mcast_dev_flush()` to remove the items while in the middle of iteration. If the mcast is
    removed while the lock was dropped, the for loop spins forever resulting in a hard lockup (as was reported
    on RHEL 4.18.0-372.75.1.el8_6 kernel): Task A (kworker/u72:2 below) | Task B (kworker/u72:0 below)
    -----------------------------------+----------------------------------- ipoib_mcast_join_task(work) |
    ipoib_ib_dev_flush_light(work) spin_lock_irq(&priv->lock) | __ipoib_ib_dev_flush(priv, ...)
    list_for_each_entry(mcast, | ipoib_mcast_dev_flush(dev = priv->dev) &priv->multicast_list, list) |
    ipoib_mcast_join(dev, mcast) | spin_unlock_irq(&priv->lock) | | spin_lock_irqsave(&priv->lock, flags) |
    list_for_each_entry_safe(mcast, tmcast, | &priv->multicast_list, list) | list_del(&mcast->list); |
    list_add_tail(&mcast->list, &remove_list) | spin_unlock_irqrestore(&priv->lock, flags)
    spin_lock_irq(&priv->lock) | | ipoib_mcast_remove_list(&remove_list) (Here, `mcast` is no longer on the |
    list_for_each_entry_safe(mcast, tmcast, `priv->multicast_list` and we keep | remove_list, list) spinning
    on the `remove_list` of | >>> wait_for_completion(&mcast->done) the other thread which is blocked | and
    the list is still valid on | it's stack.) Fix this by keeping the lock held and changing to GFP_ATOMIC to
    prevent eventual sleeps. Unfortunately we could not reproduce the lockup and confirm this fix but based on
    the code review I think this fix should address such lockups. crash> bc 31 PID: 747 TASK: ff1c6a1a007e8000
    CPU: 31 COMMAND: kworker/u72:2 -- [exception RIP: ipoib_mcast_join_task+0x1b1] RIP: ffffffffc0944ac1
    RSP: ff646f199a8c7e00 RFLAGS: 00000002 RAX: 0000000000000000 RBX: ff1c6a1a04dc82f8 RCX: 0000000000000000
    work (&priv->mcast_task{,.work}) RDX: ff1c6a192d60ac68 RSI: 0000000000000286 RDI: ff1c6a1a04dc8000
    &mcast->list RBP: ff646f199a8c7e90 R8: ff1c699980019420 R9: ff1c6a1920c9a000 R10: ff646f199a8c7e00 R11:
    ff1c6a191a7d9800 R12: ff1c6a192d60ac00 mcast R13: ff1c6a1d82200000 R14: ff1c6a1a04dc8000 R15:
    ff1c6a1a04dc82d8 dev priv (&priv->lock) &priv->multicast_list (aka head) ORIG_RAX: ffffffffffffffff CS:
    0010 SS: 0018 --- <NMI exception stack> --- #5 [ff646f199a8c7e00] ipoib_mcast_join_task+0x1b1 at
    ffffffffc0944ac1 [ib_ipoib] #6 [ff646f199a8c7e98] process_one_work+0x1a7 at ffffffff9bf10967 crash> rx
    ff646f199a8c7e68 ff646f199a8c7e68: ff1c6a1a04dc82f8 <<< work = &priv->mcast_task.work crash> list -hO
    ipoib_dev_priv.multicast_list ff1c6a1a04dc8000 (empty) crash>
    ipoib_dev_priv.mcast_task.work.func,mcast_mutex.owner.counter ff1c6a1a04dc8000 mcast_task.work.func =
    0xffffffffc0944910 <ipoib_mcast_join_task>, mcast_mutex.owner.counter = 0xff1c69998efec000 crash> b 8 PID:
    8 TASK: ff1c69998efec000 CPU: 33 COMMAND: kworker/u72:0 -- #3 [ff646f1980153d50]
    wait_for_completion+0x96 at ffffffff9c7d7646 #4 [ff646f1980153d90] ipoib_mcast_remove_list+0x56 at
    ffffffffc0944dc6 [ib_ipoib] #5 [ff646f1980153de8] ipoib_mcast_dev_flush+0x1a7 at ffffffffc09455a7
    [ib_ipoib] #6 [ff646f1980153e58] __ipoib_ib_dev_flush+0x1a4 at ffffffffc09431a4 [ib_ipoib] #7 [ff
    ---truncated--- (CVE-2023-52587)

  - In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to tag gcing flag on page
    during block migration It needs to add missing gcing flag on page during block migration, in order to
    garantee migrated data be persisted during checkpoint, otherwise out-of-order persistency between data and
    node may cause data corruption after SPOR. Similar issue was fixed by commit 2d1fe8a86bf5 (f2fs: fix to
    tag gcing flag on page during file defragment). (CVE-2023-52588)

  - In the Linux kernel, the following vulnerability has been resolved: media: rkisp1: Fix IRQ disable race
    issue In rkisp1_isp_stop() and rkisp1_csi_disable() the driver masks the interrupts and then apparently
    assumes that the interrupt handler won't be running, and proceeds in the stop procedure. This is not the
    case, as the interrupt handler can already be running, which would lead to the ISP being disabled while
    the interrupt handler handling a captured frame. This brings up two issues: 1) the ISP could be powered
    off while the interrupt handler is still running and accessing registers, leading to board lockup, and 2)
    the interrupt handler code and the code that disables the streaming might do things that conflict. It is
    not clear to me if 2) causes a real issue, but 1) can be seen with a suitable delay (or printk in my case)
    in the interrupt handler, leading to board lockup. (CVE-2023-52589)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: wfx: fix possible NULL pointer
    dereference in wfx_set_mfp_ap() Since 'ieee80211_beacon_get()' can return NULL, 'wfx_set_mfp_ap()' should
    check the return value before examining skb data. So convert the latter to return an appropriate error
    code and propagate it to return from 'wfx_start_ap()' as well. Compile tested only. (CVE-2023-52593)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: Fix potential array-
    index-out-of-bounds read in ath9k_htc_txstatus() Fix an array-index-out-of-bounds read in
    ath9k_htc_txstatus(). The bug occurs when txs->cnt, data from a URB provided by a USB device, is bigger
    than the size of the array txs->txstatus, which is HTC_MAX_TX_STATUS. WARN_ON() already checks it, but
    there is no bug handling code after the check. Make the function return if that is the case. Found by a
    modified version of syzkaller. UBSAN: array-index-out-of-bounds in htc_drv_txrx.c index 13 is out of range
    for type '__wmi_event_txstatus [12]' Call Trace: ath9k_htc_txstatus ath9k_wmi_event_tasklet
    tasklet_action_common __do_softirq irq_exit_rxu sysvec_apic_timer_interrupt (CVE-2023-52594)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: rt2x00: restart beacon queue
    when hardware reset When a hardware reset is triggered, all registers are reset, so all queues are forced
    to stop in hardware interface. However, mac80211 will not automatically stop the queue. If we don't
    manually stop the beacon queue, the queue will be deadlocked and unable to start again. This patch fixes
    the issue where Apple devices cannot connect to the AP after calling ieee80211_restart_hw().
    (CVE-2023-52595)

  - In the Linux kernel, the following vulnerability has been resolved: KVM: s390: fix setting of fpc register
    kvm_arch_vcpu_ioctl_set_fpu() allows to set the floating point control (fpc) register of a guest cpu. The
    new value is tested for validity by temporarily loading it into the fpc register. This may lead to
    corruption of the fpc register of the host process: if an interrupt happens while the value is temporarily
    loaded into the fpc register, and within interrupt context floating point or vector registers are used,
    the current fp/vx registers are saved with save_fpu_regs() assuming they belong to user space and will be
    loaded into fp/vx registers when returning to user space. test_fp_ctl() restores the original user space /
    host process fpc register value, however it will be discarded, when returning to user space. In result the
    host process will incorrectly continue to run with the value that was supposed to be used for a guest cpu.
    Fix this by simply removing the test. There is another test right before the SIE context is entered which
    will handles invalid values. This results in a change of behaviour: invalid values will now be accepted
    instead of that the ioctl fails with -EINVAL. This seems to be acceptable, given that this interface is
    most likely not used anymore, and this is in addition the same behaviour implemented with the memory
    mapped interface (replace invalid values with zero) - see sync_regs() in kvm-s390.c. (CVE-2023-52597)

  - In the Linux kernel, the following vulnerability has been resolved: s390/ptrace: handle setting of fpc
    register correctly If the content of the floating point control (fpc) register of a traced process is
    modified with the ptrace interface the new value is tested for validity by temporarily loading it into the
    fpc register. This may lead to corruption of the fpc register of the tracing process: if an interrupt
    happens while the value is temporarily loaded into the fpc register, and within interrupt context floating
    point or vector registers are used, the current fp/vx registers are saved with save_fpu_regs() assuming
    they belong to user space and will be loaded into fp/vx registers when returning to user space.
    test_fp_ctl() restores the original user space fpc register value, however it will be discarded, when
    returning to user space. In result the tracer will incorrectly continue to run with the value that was
    supposed to be used for the traced process. Fix this by saving fpu register contents with save_fpu_regs()
    before using test_fp_ctl(). (CVE-2023-52598)

  - In the Linux kernel, the following vulnerability has been resolved: jfs: fix array-index-out-of-bounds in
    diNewExt [Syz report] UBSAN: array-index-out-of-bounds in fs/jfs/jfs_imap.c:2360:2 index -878706688 is out
    of range for type 'struct iagctl[128]' CPU: 1 PID: 5065 Comm: syz-executor282 Not tainted
    6.7.0-rc4-syzkaller-00009-gbee0e7762ad2 #0 Hardware name: Google Google Compute Engine/Google Compute
    Engine, BIOS Google 11/10/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline]
    dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:217 [inline]
    __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348 diNewExt+0x3cf3/0x4000 fs/jfs/jfs_imap.c:2360
    diAllocExt fs/jfs/jfs_imap.c:1949 [inline] diAllocAG+0xbe8/0x1e50 fs/jfs/jfs_imap.c:1666
    diAlloc+0x1d3/0x1760 fs/jfs/jfs_imap.c:1587 ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56 jfs_mkdir+0x1c5/0xb90
    fs/jfs/namei.c:225 vfs_mkdir+0x2f1/0x4b0 fs/namei.c:4106 do_mkdirat+0x264/0x3a0 fs/namei.c:4129
    __do_sys_mkdir fs/namei.c:4149 [inline] __se_sys_mkdir fs/namei.c:4147 [inline] __x64_sys_mkdir+0x6e/0x80
    fs/namei.c:4147 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x45/0x110
    arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7fcb7e6a0b57 Code: ff ff
    77 07 31 c0 c3 0f 1f 40 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 b8 53
    00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP:
    002b:00007ffd83023038 EFLAGS: 00000286 ORIG_RAX: 0000000000000053 RAX: ffffffffffffffda RBX:
    00000000ffffffff RCX: 00007fcb7e6a0b57 RDX: 00000000000a1020 RSI: 00000000000001ff RDI: 0000000020000140
    RBP: 0000000020000140 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11:
    0000000000000286 R12: 00007ffd830230d0 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
    [Analysis] When the agstart is too large, it can cause agno overflow. [Fix] After obtaining agno, if the
    value is invalid, exit the subsequent process. Modified the test from agno > MAXAG to agno >= MAXAG based
    on linux-next report by kernel test robot (Dan Carpenter). (CVE-2023-52599)

  - In the Linux kernel, the following vulnerability has been resolved: jfs: fix uaf in jfs_evict_inode When
    the execution of diMount(ipimap) fails, the object ipimap that has been released may be accessed in
    diFreeSpecial(). Asynchronous ipimap release occurs when rcu_core() calls jfs_free_node(). Therefore, when
    diMount(ipimap) fails, sbi->ipimap should not be initialized as ipimap. (CVE-2023-52600)

  - In the Linux kernel, the following vulnerability has been resolved: jfs: fix array-index-out-of-bounds in
    dbAdjTree Currently there is a bound check missing in the dbAdjTree while accessing the dmt_stree. To add
    the required check added the bool is_ctl which is required to determine the size as suggest in the
    following commit. https://lore.kernel.org/linux-kernel-
    mentees/[email protected]/ (CVE-2023-52601)

  - In the Linux kernel, the following vulnerability has been resolved: jfs: fix slab-out-of-bounds Read in
    dtSearch Currently while searching for current page in the sorted entry table of the page there is a out
    of bound access. Added a bound check to fix the error. Dave: Set return code to -EIO (CVE-2023-52602)

  - In the Linux kernel, the following vulnerability has been resolved: UBSAN: array-index-out-of-bounds in
    dtSplitRoot Syzkaller reported the following issue: oop0: detected capacity change from 0 to 32768 UBSAN:
    array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9 index -2 is out of range for type 'struct dtslot
    [128]' CPU: 0 PID: 3613 Comm: syz-executor270 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0 Hardware
    name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Call Trace: <TASK>
    __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 ubsan_epilogue
    lib/ubsan.c:151 [inline] __ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283 dtSplitRoot+0x8d8/0x1900
    fs/jfs/jfs_dtree.c:1971 dtSplitUp fs/jfs/jfs_dtree.c:985 [inline] dtInsert+0x1189/0x6b80
    fs/jfs/jfs_dtree.c:863 jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270 vfs_mkdir+0x3b3/0x590 fs/namei.c:4013
    do_mkdirat+0x279/0x550 fs/namei.c:4038 __do_sys_mkdirat fs/namei.c:4053 [inline] __se_sys_mkdirat
    fs/namei.c:4051 [inline] __x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051 do_syscall_x64
    arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fcdc0113fd9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00
    00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0
    ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffeb8bc67d8 EFLAGS: 00000246
    ORIG_RAX: 0000000000000102 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcdc0113fd9 RDX:
    0000000000000000 RSI: 0000000020000340 RDI: 0000000000000003 RBP: 00007fcdc00d37a0 R08: 0000000000000000
    R09: 00007fcdc00d37a0 R10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000 R13:
    0000000000000000 R14: 00083878000000f8 R15: 0000000000000000 </TASK> The issue is caused when the value of
    fsi becomes less than -1. The check to break the loop when fsi value becomes -1 is present but syzbot was
    able to produce value less than -1 which cause the error. This patch simply add the change for the values
    less than 0. The patch is tested via syzbot. (CVE-2023-52603)

  - In the Linux kernel, the following vulnerability has been resolved: FS:JFS:UBSAN:array-index-out-of-bounds
    in dbAdjTree Syzkaller reported the following issue: UBSAN: array-index-out-of-bounds in
    fs/jfs/jfs_dmap.c:2867:6 index 196694 is out of range for type 's8[1365]' (aka 'signed char[1365]') CPU: 1
    PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0 Hardware name: Google Google Compute
    Engine/Google Compute Engine, BIOS Google 08/04/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88
    [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:217 [inline]
    __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348 dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867
    dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834 dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331 dbFreeDmap
    fs/jfs/jfs_dmap.c:2080 [inline] dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402 txFreeMap+0x798/0xd50
    fs/jfs/jfs_txnmgr.c:2534 txUpdateMap+0x342/0x9e0 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]
    jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732 kthread+0x2d3/0x370 kernel/kthread.c:388
    ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20
    arch/x86/entry/entry_64.S:304 </TASK>
    ================================================================================ Kernel panic - not
    syncing: UBSAN: panic_on_warn set ... CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023 Call Trace:
    <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
    panic+0x30f/0x770 kernel/panic.c:340 check_panic_on_warn+0x82/0xa0 kernel/panic.c:236 ubsan_epilogue
    lib/ubsan.c:223 [inline] __ubsan_handle_out_of_bounds+0x13c/0x150 lib/ubsan.c:348 dbAdjTree+0x474/0x4f0
    fs/jfs/jfs_dmap.c:2867 dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834 dbFreeBits+0x4eb/0xda0
    fs/jfs/jfs_dmap.c:2331 dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline] dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402
    txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534 txUpdateMap+0x342/0x9e0 txLazyCommit
    fs/jfs/jfs_txnmgr.c:2664 [inline] jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732 kthread+0x2d3/0x370
    kernel/kthread.c:388 ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20
    arch/x86/entry/entry_64.S:304 </TASK> Kernel Offset: disabled Rebooting in 86400 seconds.. The issue is
    caused when the value of lp becomes greater than CTLTREESIZE which is the max size of stree. Adding a
    simple check solves this issue. Dave: As the function returns a void, good error handling would require a
    more intrusive code reorganization, so I modified Osama's patch at use WARN_ON_ONCE for lack of a cleaner
    option. The patch is tested via syzbot. (CVE-2023-52604)

  - In the Linux kernel, the following vulnerability has been resolved: ACPI: extlog: fix NULL pointer
    dereference check The gcc plugin -fanalyzer [1] tries to detect various patterns of incorrect behaviour.
    The tool reports: drivers/acpi/acpi_extlog.c: In function extlog_exit':
    drivers/acpi/acpi_extlog.c:307:12: warning: check of extlog_l1_addr' for NULL after already dereferencing
    it [-Wanalyzer-deref-before-check] | | 306 | ((struct extlog_l1_head *)extlog_l1_addr)->flags &=
    ~FLAG_OS_OPTIN; | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ | | | | | (1) pointer
    extlog_l1_addr' is dereferenced here | 307 | if (extlog_l1_addr) | | ~ | | | | | (2) pointer
    extlog_l1_addr' is checked for NULL here but it was already dereferenced at (1) | Fix the NULL pointer
    dereference check in extlog_exit(). (CVE-2023-52605)

  - In the Linux kernel, the following vulnerability has been resolved: powerpc/lib: Validate size for vector
    operations Some of the fp/vmx code in sstep.c assume a certain maximum size for the instructions being
    emulated. The size of those operations however is determined separately in analyse_instr(). Add a check to
    validate the assumption on the maximum size of the operations, so as to prevent any unintended kernel
    stack corruption. (CVE-2023-52606)

  - In the Linux kernel, the following vulnerability has been resolved: powerpc/mm: Fix null-pointer
    dereference in pgtable_cache_add kasprintf() returns a pointer to dynamically allocated memory which can
    be NULL upon failure. Ensure the allocation was successful by checking the pointer validity.
    (CVE-2023-52607)

  - The reference count changes made as part of the CVE-2023-33951 and CVE-2023-33952 fixes exposed a use-
    after-free flaw in the way memory objects were handled when they were being used to store a surface. When
    running inside a VMware guest with 3D acceleration enabled, a local, unprivileged user could potentially
    use this flaw to escalate their privileges. (CVE-2023-5633)

  - An out-of-bounds read vulnerability was found in smb2_dump_detail in fs/smb/client/smb2ops.c in the Linux
    Kernel. This issue could allow a local attacker to crash the system or leak internal kernel information.
    (CVE-2023-6610)

  - A vulnerability was found in vhost_new_msg in drivers/vhost/vhost.c in the Linux kernel, which does not
    properly initialize memory in messages passed between virtual guests and the host operating system in the
    vhost/vhost.c:vhost_new_msg() function. This issue can allow local privileged users to read some kernel
    memory contents when reading from the /dev/vhost-net device file. (CVE-2024-0340)

  - A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to
    achieve local privilege escalation. The nft_setelem_catchall_deactivate() function checks whether the
    catch-all set element is active in the current generation instead of the next generation before freeing
    it, but only flags it inactive in the next generation, making it possible to free the element multiple
    times, leading to a double free vulnerability. We recommend upgrading past commit
    b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7. (CVE-2024-1085)

  - A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to
    achieve local privilege escalation. The nft_verdict_init() function allows positive values as drop error
    within the hook verdict, and hence the nf_hook_slow() function can cause a double free vulnerability when
    NF_DROP is issued with a drop error which resembles NF_ACCEPT. We recommend upgrading past commit
    f342de4e2f33e0e39165d8639387aa6c19dff660. (CVE-2024-1086)

  - In rds_recv_track_latency in net/rds/af_rds.c in the Linux kernel through 6.7.1, there is an off-by-one
    error for an RDS_MSG_RX_DGRAM_TRACE_MAX comparison, resulting in out-of-bounds access. (CVE-2024-23849)

  - A race condition was found in the Linux kernel's bluetooth device driver in {min,max}_key_size_set()
    function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or
    denial of service issue. (CVE-2024-24860)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: skip end
    interval element from gc rbtree lazy gc on insert might collect an end interval element that has been just
    added in this transactions, skip end interval elements that are not yet active. (CVE-2024-26581)

  - In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Prevent out-of-bounds
    memory access The test_tag test triggers an unhandled page fault: # ./test_tag [ 130.640218] CPU 0 Unable
    to handle kernel paging request at virtual address ffff80001b898004, era == 9000000003137f7c, ra ==
    9000000003139e70 [ 130.640501] Oops[#3]: [ 130.640553] CPU: 0 PID: 1326 Comm: test_tag Tainted: G D O
    6.7.0-rc4-loong-devel-gb62ab1a397cf #47 61985c1d94084daa2432f771daa45b56b10d8d2a [ 130.640764] Hardware
    name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 [ 130.640874] pc 9000000003137f7c ra
    9000000003139e70 tp 9000000104cb4000 sp 9000000104cb7a40 [ 130.641001] a0 ffff80001b894000 a1
    ffff80001b897ff8 a2 000000006ba210be a3 0000000000000000 [ 130.641128] a4 000000006ba210be a5
    00000000000000f1 a6 00000000000000b3 a7 0000000000000000 [ 130.641256] t0 0000000000000000 t1
    00000000000007f6 t2 0000000000000000 t3 9000000004091b70 [ 130.641387] t4 000000006ba210be t5
    0000000000000004 t6 fffffffffffffff0 t7 90000000040913e0 [ 130.641512] t8 0000000000000005 u0
    0000000000000dc0 s9 0000000000000009 s0 9000000104cb7ae0 [ 130.641641] s1 00000000000007f6 s2
    0000000000000009 s3 0000000000000095 s4 0000000000000000 [ 130.641771] s5 ffff80001b894000 s6
    ffff80001b897fb0 s7 9000000004090c50 s8 0000000000000000 [ 130.641900] ra: 9000000003139e70
    build_body+0x1fcc/0x4988 [ 130.642007] ERA: 9000000003137f7c build_body+0xd8/0x4988 [ 130.642112] CRMD:
    000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 130.642261] PRMD: 00000004 (PPLV0 +PIE -PWE) [
    130.642353] EUEN: 00000003 (+FPE +SXE -ASXE -BTE) [ 130.642458] ECFG: 00071c1c (LIE=2-4,10-12 VS=7) [
    130.642554] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) [ 130.642658] BADV: ffff80001b898004 [
    130.642719] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) [ 130.642815] Modules linked in: [last
    unloaded: bpf_testmod(O)] [ 130.642924] Process test_tag (pid: 1326, threadinfo=00000000f7f4015f,
    task=000000006499f9fd) [ 130.643062] Stack : 0000000000000000 9000000003380724 0000000000000000
    0000000104cb7be8 [ 130.643213] 0000000000000000 25af8d9b6e600558 9000000106250ea0 9000000104cb7ae0 [
    130.643378] 0000000000000000 0000000000000000 9000000104cb7be8 90000000049f6000 [ 130.643538]
    0000000000000090 9000000106250ea0 ffff80001b894000 ffff80001b894000 [ 130.643685] 00007ffffb917790
    900000000313ca94 0000000000000000 0000000000000000 [ 130.643831] ffff80001b894000 0000000000000ff7
    0000000000000000 9000000100468000 [ 130.643983] 0000000000000000 0000000000000000 0000000000000040
    25af8d9b6e600558 [ 130.644131] 0000000000000bb7 ffff80001b894048 0000000000000000 0000000000000000 [
    130.644276] 9000000104cb7be8 90000000049f6000 0000000000000090 9000000104cb7bdc [ 130.644423]
    ffff80001b894000 0000000000000000 00007ffffb917790 90000000032acfb0 [ 130.644572] ... [ 130.644629] Call
    Trace: [ 130.644641] [<9000000003137f7c>] build_body+0xd8/0x4988 [ 130.644785] [<900000000313ca94>]
    bpf_int_jit_compile+0x228/0x4ec [ 130.644891] [<90000000032acfb0>] bpf_prog_select_runtime+0x158/0x1b0 [
    130.645003] [<90000000032b3504>] bpf_prog_load+0x760/0xb44 [ 130.645089] [<90000000032b6744>]
    __sys_bpf+0xbb8/0x2588 [ 130.645175] [<90000000032b8388>] sys_bpf+0x20/0x2c [ 130.645259]
    [<9000000003f6ab38>] do_syscall+0x7c/0x94 [ 130.645369] [<9000000003121c5c>] handle_syscall+0xbc/0x158 [
    130.645507] [ 130.645539] Code: 380839f6 380831f9 28412bae <24000ca6> 004081ad 0014cb50 004083e8 02bff34c
    58008e91 [ 130.645729] [ 130.646418] ---[ end trace 0000000000000000 ]--- On my machine, which has
    CONFIG_PAGE_SIZE_16KB=y, the test failed at loading a BPF prog with 2039 instructions: prog = (struct
    bpf_prog *)ffff80001b894000 insn = (struct bpf_insn *)(prog->insnsi)fff ---truncated--- (CVE-2024-26588)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Reject variable offset alu on
    PTR_TO_FLOW_KEYS For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off for validation.
    However, variable offset ptr alu is not prohibited for this ptr kind. So the variable offset is not
    checked. The following prog is accepted: func#0 @0 0: R1=ctx() R10=fp0 0: (bf) r6 = r1 ; R1=ctx()
    R6_w=ctx() 1: (79) r7 = *(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flow_keys() 2: (b7) r8 = 1024 ; R8_w=1024 3:
    (37) r8 /= 1 ; R8_w=scalar() 4: (57) r8 &= 1024 ; R8_w=scalar(smin=smin32=0,
    smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400)) 5: (0f) r7 += r8 mark_precise: frame0: last_idx 5
    first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &= 1024 mark_precise:
    frame0: regs=r8 stack= before 3: (37) r8 /= 1 mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 =
    1024 6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off =(0x0; 0x400))
    R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024, var_off=(0x0; 0x400)) 6: (79) r0 = *(u64 *)(r7 +0)
    ; R0_w=scalar() 7: (95) exit This prog loads flow_keys to r7, and adds the variable offset r8 to r7, and
    finally causes out-of-bounds access: BUG: unable to handle page fault for address: ffffc90014c80038 [...]
    Call Trace: <TASK> bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline] __bpf_prog_run
    include/linux/filter.h:651 [inline] bpf_prog_run include/linux/filter.h:658 [inline]
    bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline] bpf_flow_dissect+0x15f/0x350
    net/core/flow_dissector.c:991 bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359
    bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline] __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475
    __do_sys_bpf kernel/bpf/syscall.c:5561 [inline] __se_sys_bpf kernel/bpf/syscall.c:5559 [inline]
    __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
    do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Fix this by
    rejecting ptr alu with variable offset on flow_keys. Applying the patch rejects the program with R7
    pointer arithmetic on flow_keys prohibited. (CVE-2024-26589)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Fix re-attachment branch in
    bpf_tracing_prog_attach The following case can cause a crash due to missing attach_btf: 1) load rawtp
    program 2) load fentry program with rawtp as target_fd 3) create tracing link for fentry program with
    target_fd = 0 4) repeat 3 In the end we have: - prog->aux->dst_trampoline == NULL - tgt_prog == NULL
    (because we did not provide target_fd to link_create) - prog->aux->attach_btf == NULL (the program was
    loaded with attach_prog_fd=X) - the program was loaded for tgt_prog but we have no way to find out which
    one BUG: kernel NULL pointer dereference, address: 0000000000000058 Call Trace: <TASK> ? __die+0x20/0x70 ?
    page_fault_oops+0x15b/0x430 ? fixup_exception+0x22/0x330 ? exc_page_fault+0x6f/0x170 ?
    asm_exc_page_fault+0x22/0x30 ? bpf_tracing_prog_attach+0x279/0x560 ? btf_obj_id+0x5/0x10
    bpf_tracing_prog_attach+0x439/0x560 __sys_bpf+0x1cf4/0x2de0 __x64_sys_bpf+0x1c/0x30
    do_syscall_64+0x41/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Return -EINVAL in this situation.
    (CVE-2024-26591)

  - In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix UAF issue in
    ksmbd_tcp_new_connection() The race is between the handling of a new TCP connection and its disconnection.
    It leads to UAF on `struct tcp_transport` in ksmbd_tcp_new_connection() function. (CVE-2024-26592)

  - In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate mech token in session
    setup If client send invalid mech token in session setup request, ksmbd validate and make the error if it
    is invalid. (CVE-2024-26594)

  - In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: fix global oob
    in rmnet_policy The variable rmnet_link_ops assign a *bigger* maxtype which leads to a global out-of-
    bounds read when parsing the netlink attributes. See bug trace below:
    ================================================================== BUG: KASAN: global-out-of-bounds in
    validate_nla lib/nlattr.c:386 [inline] BUG: KASAN: global-out-of-bounds in
    __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600 Read of size 1 at addr ffffffff92c438d0 by task syz-
    executor.6/84207 CPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G N 6.1.0 #3 Hardware name: QEMU Standard
    PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> __dump_stack
    lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106 print_address_description
    mm/kasan/report.c:284 [inline] print_report+0x172/0x475 mm/kasan/report.c:395 kasan_report+0xbb/0x1c0
    mm/kasan/report.c:495 validate_nla lib/nlattr.c:386 [inline] __nla_validate_parse+0x24af/0x2750
    lib/nlattr.c:600 __nla_parse+0x3e/0x50 lib/nlattr.c:697 nla_parse_nested_deprecated
    include/net/netlink.h:1248 [inline] __rtnl_newlink+0x50a/0x1880 net/core/rtnetlink.c:3485
    rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3594 rtnetlink_rcv_msg+0x43c/0xd70 net/core/rtnetlink.c:6091
    netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540 netlink_unicast_kernel
    net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345
    netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline]
    sock_sendmsg+0x154/0x190 net/socket.c:734 ____sys_sendmsg+0x6df/0x840 net/socket.c:2482
    ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536 __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565 do_syscall_x64
    arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fdcf2072359 Code: 28 00 00 00 75 05 48 83 c4 28 c3
    e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0
    ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fdcf13e3168 EFLAGS: 00000246
    ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fdcf219ff80 RCX: 00007fdcf2072359 RDX:
    0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003 RBP: 00007fdcf20bd493 R08: 0000000000000000
    R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13:
    00007fffbb8d7bdf R14: 00007fdcf13e3300 R15: 0000000000022000 </TASK> The buggy address belongs to the
    variable: rmnet_policy+0x30/0xe0 The buggy address belongs to the physical page: page:0000000065bdeb3c
    refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243 flags:
    0x200000000001000(reserved|node=0|zone=2) raw: 0200000000001000 ffffea00055490c8 ffffea00055490c8
    0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped
    because: kasan: bad access detected Memory state around the buggy address: ffffffff92c43780: f9 f9 f9 f9
    00 00 00 02 f9 f9 f9 f9 00 00 00 07 ffffffff92c43800: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9
    >ffffffff92c43880: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 ^ ffffffff92c43900: 00 00 00 00 00 00
    00 00 07 f9 f9 f9 f9 f9 f9 f9 ffffffff92c43980: 00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 According
    to the comment of `nla_parse_nested_deprecated`, the maxtype should be len(destination array) - 1. Hence
    use `IFLA_RMNET_MAX` here. (CVE-2024-26597)

  - In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Avoid potential
    UAF in LPI translation cache There is a potential UAF scenario in the case of an LPI translation cache hit
    racing with an operation that invalidates the cache, such as a DISCARD ITS command. The root of the
    problem is that vgic_its_check_cache() does not elevate the refcount on the vgic_irq before dropping the
    lock that serializes refcount changes. Have vgic_its_check_cache() raise the refcount on the returned
    vgic_irq and add the corresponding decrement after queueing the interrupt. (CVE-2024-26598)

  - In the Linux kernel, the following vulnerability has been resolved: pwm: Fix out-of-bounds access in
    of_pwm_single_xlate() With args->args_count == 2 args->args[2] is not defined. Actually the flags are
    contained in args->args[1]. (CVE-2024-26599)

  - In the Linux kernel, the following vulnerability has been resolved: phy: ti: phy-omap-usb2: Fix NULL
    pointer dereference for SRP If the external phy working together with phy-omap-usb2 does not implement
    send_srp(), we may still attempt to call it. This can happen on an idle Ethernet gadget triggering a
    wakeup for example: configfs-gadget.g1 gadget.0: ECM Suspend configfs-gadget.g1 gadget.0: Port suspended.
    Triggering wakeup ... Unable to handle kernel NULL pointer dereference at virtual address 00000000 when
    execute ... PC is at 0x0 LR is at musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc] ... musb_gadget_wakeup
    [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core] usb_gadget_wakeup [udc_core] from
    eth_start_xmit+0x3b0/0x3d4 [u_ether] eth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24c
    dev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4 sch_direct_xmit from __dev_queue_xmit+0x334/0xd88
    __dev_queue_xmit from arp_solicit+0xf0/0x268 arp_solicit from neigh_probe+0x54/0x7c neigh_probe from
    __neigh_event_send+0x22c/0x47c __neigh_event_send from neigh_resolve_output+0x14c/0x1c0
    neigh_resolve_output from ip_finish_output2+0x1c8/0x628 ip_finish_output2 from ip_send_skb+0x40/0xd8
    ip_send_skb from udp_send_skb+0x124/0x340 udp_send_skb from udp_sendmsg+0x780/0x984 udp_sendmsg from
    __sys_sendto+0xd8/0x158 __sys_sendto from ret_fast_syscall+0x0/0x58 Let's fix the issue by checking for
    send_srp() and set_vbus() before calling them. For USB peripheral only cases these both could be NULL.
    (CVE-2024-26600)

  - In the Linux kernel, the following vulnerability has been resolved: ext4: regenerate buddy after block
    freeing failed if under fc replay This mostly reverts commit 6bd97bf273bd (ext4: remove redundant
    mb_regenerate_buddy()) and reintroduces mb_regenerate_buddy(). Based on code in mb_free_blocks(), fast
    commit replay can end up marking as free blocks that are already marked as such. This causes corruption of
    the buddy bitmap so we need to regenerate it in that case. (CVE-2024-26601)

  - In the Linux kernel, the following vulnerability has been resolved: af_unix: fix lockdep positive in
    sk_diag_dump_icons() syzbot reported a lockdep splat [1]. Blamed commit hinted about the possible lockdep
    violation, and code used unix_state_lock_nested() in an attempt to silence lockdep. It is not sufficient,
    because unix_state_lock_nested() is already used from unix_state_double_lock(). We need to use a separate
    subclass. This patch adds a distinct enumeration to make things more explicit. Also use swap() in
    unix_state_double_lock() as a clean up. v2: add a missing inline keyword to unix_state_lock_nested() [1]
    WARNING: possible circular locking dependency detected 6.8.0-rc1-syzkaller-00356-g8a696a29c690 #0 Not
    tainted syz-executor.1/2542 is trying to acquire lock: ffff88808b5df9e8 (rlock-AF_UNIX){+.+.}-{2:2}, at:
    skb_queue_tail+0x36/0x120 net/core/skbuff.c:3863 but task is already holding lock: ffff88808b5dfe70
    (&u->lock/1){+.+.}-{2:2}, at: unix_dgram_sendmsg+0xfc7/0x2200 net/unix/af_unix.c:2089 which lock already
    depends on the new lock. the existing dependency chain (in reverse order) is: -> #1
    (&u->lock/1){+.+.}-{2:2}: lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754
    _raw_spin_lock_nested+0x31/0x40 kernel/locking/spinlock.c:378 sk_diag_dump_icons net/unix/diag.c:87
    [inline] sk_diag_fill+0x6ea/0xfe0 net/unix/diag.c:157 sk_diag_dump net/unix/diag.c:196 [inline]
    unix_diag_dump+0x3e9/0x630 net/unix/diag.c:220 netlink_dump+0x5c1/0xcd0 net/netlink/af_netlink.c:2264
    __netlink_dump_start+0x5d7/0x780 net/netlink/af_netlink.c:2370 netlink_dump_start
    include/linux/netlink.h:338 [inline] unix_diag_handler_dump+0x1c3/0x8f0 net/unix/diag.c:319
    sock_diag_rcv_msg+0xe3/0x400 netlink_rcv_skb+0x1df/0x430 net/netlink/af_netlink.c:2543
    sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280 netlink_unicast_kernel net/netlink/af_netlink.c:1341
    [inline] netlink_unicast+0x7e6/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa37/0xd70
    net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745
    [inline] sock_write_iter+0x39a/0x520 net/socket.c:1160 call_write_iter include/linux/fs.h:2085 [inline]
    new_sync_write fs/read_write.c:497 [inline] vfs_write+0xa74/0xca0 fs/read_write.c:590
    ksys_write+0x1a0/0x2c0 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
    do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b -> #0 (rlock-
    AF_UNIX){+.+.}-{2:2}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add
    kernel/locking/lockdep.c:3253 [inline] validate_chain+0x1909/0x5ab0 kernel/locking/lockdep.c:3869
    __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1e3/0x530
    kernel/locking/lockdep.c:5754 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
    _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 skb_queue_tail+0x36/0x120
    net/core/skbuff.c:3863 unix_dgram_sendmsg+0x15d9/0x2200 net/unix/af_unix.c:2112 sock_sendmsg_nosec
    net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x592/0x890
    net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmmsg+0x3b2/0x730 net/socket.c:2724
    __do_sys_sendmmsg net/socket.c:2753 [inline] __se_sys_sendmmsg net/socket.c:2750 [inline]
    __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2750 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
    do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b other info
    that might help us debug this: Possible unsafe locking scenario: CPU0 ---truncated--- (CVE-2024-26624)

  - In the Linux kernel, the following vulnerability has been resolved: llc: call sock_orphan() at release
    time syzbot reported an interesting trace [1] caused by a stale sk->sk_wq pointer in a closed llc socket.
    In commit ff7b11aa481f (net: socket: set sock->sk to NULL after calling proto_ops::release()) Eric
    Biggers hinted that some protocols are missing a sock_orphan(), we need to perform a full audit. In net-
    next, I plan to clear sock->sk from sock_orphan() and amend Eric patch to add a warning. [1] BUG: KASAN:
    slab-use-after-free in list_empty include/linux/list.h:373 [inline] BUG: KASAN: slab-use-after-free in
    waitqueue_active include/linux/wait.h:127 [inline] BUG: KASAN: slab-use-after-free in
    sock_def_write_space_wfree net/core/sock.c:3384 [inline] BUG: KASAN: slab-use-after-free in
    sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468 Read of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27
    CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0 Hardware name:
    QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Call Trace: <TASK>
    __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
    print_address_description mm/kasan/report.c:377 [inline] print_report+0xc4/0x620 mm/kasan/report.c:488
    kasan_report+0xda/0x110 mm/kasan/report.c:601 list_empty include/linux/list.h:373 [inline]
    waitqueue_active include/linux/wait.h:127 [inline] sock_def_write_space_wfree net/core/sock.c:3384
    [inline] sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468 skb_release_head_state+0xa3/0x2b0
    net/core/skbuff.c:1080 skb_release_all net/core/skbuff.c:1092 [inline] napi_consume_skb+0x119/0x2b0
    net/core/skbuff.c:1404 e1000_unmap_and_free_tx_resource+0x144/0x200
    drivers/net/ethernet/intel/e1000/e1000_main.c:1970 e1000_clean_tx_irq
    drivers/net/ethernet/intel/e1000/e1000_main.c:3860 [inline] e1000_clean+0x4a1/0x26e0
    drivers/net/ethernet/intel/e1000/e1000_main.c:3801 __napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6576
    napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x956/0xe90 net/core/dev.c:6778
    __do_softirq+0x21a/0x8de kernel/softirq.c:553 run_ksoftirqd kernel/softirq.c:921 [inline]
    run_ksoftirqd+0x31/0x60 kernel/softirq.c:913 smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164
    kthread+0x2c6/0x3a0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
    ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 </TASK> Allocated by task 5167:
    kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68
    unpoison_slab_object mm/kasan/common.c:314 [inline] __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340
    kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3813 [inline]
    slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879 alloc_inode_sb
    include/linux/fs.h:3019 [inline] sock_alloc_inode+0x25/0x1c0 net/socket.c:308 alloc_inode+0x5d/0x220
    fs/inode.c:260 new_inode_pseudo+0x16/0x80 fs/inode.c:1005 sock_alloc+0x40/0x270 net/socket.c:634
    __sock_create+0xbc/0x800 net/socket.c:1535 sock_create net/socket.c:1622 [inline] __sys_socket_create
    net/socket.c:1659 [inline] __sys_socket+0x14c/0x260 net/socket.c:1706 __do_sys_socket net/socket.c:1720
    [inline] __se_sys_socket net/socket.c:1718 [inline] __x64_sys_socket+0x72/0xb0 net/socket.c:1718
    do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83
    entry_SYSCALL_64_after_hwframe+0x63/0x6b Freed by task 0: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
    kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640
    poison_slab_object mm/kasan/common.c:241 [inline] __kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257
    kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2121 [inlin ---truncated---
    (CVE-2024-26625)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: core: Move scsi_host_busy() out
    of host lock for waking up EH handler Inside scsi_eh_wakeup(), scsi_host_busy() is called & checked with
    host lock every time for deciding if error handler kthread needs to be waken up. This can be too heavy in
    case of recovery, such as: - N hardware queues - queue depth is M for each hardware queue - each
    scsi_host_busy() iterates over (N * M) tag/requests If recovery is triggered in case that all requests are
    in-flight, each scsi_eh_wakeup() is strictly serialized, when scsi_eh_wakeup() is called for the last in-
    flight request, scsi_host_busy() has been run for (N * M - 1) times, and request has been iterated for
    (N*M - 1) * (N * M) times. If both N and M are big enough, hard lockup can be triggered on acquiring host
    lock, and it is observed on mpi3mr(128 hw queues, queue depth 8169). Fix the issue by calling
    scsi_host_busy() outside the host lock. We don't need the host lock for getting busy count because host
    the lock never covers that. [mkp: Drop unnecessary 'busy' variables pointed out by Bart] (CVE-2024-26627)

  - In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix lock dependency
    warning ====================================================== WARNING: possible circular locking
    dependency detected 6.5.0-kfd-fkuehlin #276 Not tainted
    ------------------------------------------------------ kworker/8:2/2676 is trying to acquire lock:
    ffff9435aae95c88 ((work_completion)(&svm_bo->eviction_work)){+.+.}-{0:0}, at: __flush_work+0x52/0x550 but
    task is already holding lock: ffff9435cd8e1720 (&svms->lock){+.+.}-{3:3}, at:
    svm_range_deferred_list_work+0xe8/0x340 [amdgpu] which lock already depends on the new lock. the existing
    dependency chain (in reverse order) is: -> #2 (&svms->lock){+.+.}-{3:3}: __mutex_lock+0x97/0xd30
    kfd_ioctl_alloc_memory_of_gpu+0x6d/0x3c0 [amdgpu] kfd_ioctl+0x1b2/0x5d0 [amdgpu] __x64_sys_ioctl+0x86/0xc0
    do_syscall_64+0x39/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd -> #1 (&mm->mmap_lock){++++}-{3:3}:
    down_read+0x42/0x160 svm_range_evict_svm_bo_worker+0x8b/0x340 [amdgpu] process_one_work+0x27a/0x540
    worker_thread+0x53/0x3e0 kthread+0xeb/0x120 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x11/0x20 -> #0
    ((work_completion)(&svm_bo->eviction_work)){+.+.}-{0:0}: __lock_acquire+0x1426/0x2200
    lock_acquire+0xc1/0x2b0 __flush_work+0x80/0x550 __cancel_work_timer+0x109/0x190
    svm_range_bo_release+0xdc/0x1c0 [amdgpu] svm_range_free+0x175/0x180 [amdgpu]
    svm_range_deferred_list_work+0x15d/0x340 [amdgpu] process_one_work+0x27a/0x540 worker_thread+0x53/0x3e0
    kthread+0xeb/0x120 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x11/0x20 other info that might help us debug
    this: Chain exists of: (work_completion)(&svm_bo->eviction_work) --> &mm->mmap_lock --> &svms->lock
    Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&svms->lock); lock(&mm->mmap_lock);
    lock(&svms->lock); lock((work_completion)(&svm_bo->eviction_work)); I believe this cannot really lead to a
    deadlock in practice, because svm_range_evict_svm_bo_worker only takes the mmap_read_lock if the BO
    refcount is non-0. That means it's impossible that svm_range_bo_release is running concurrently. However,
    there is no good way to annotate this. To avoid the problem, take a BO reference in
    svm_range_schedule_evict_svm_bo instead of in the worker. That way it's impossible for a BO to get freed
    while eviction work is pending and the cancel_work_sync call in svm_range_bo_release can be eliminated.
    v2: Use svm_bo_ref_unless_zero and explained why that's safe. Also removed redundant checks that are
    already done in amdkfd_fence_enable_signaling. (CVE-2024-26628)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version
number.");
  script_set_attribute(attribute:"see_also", value:"https://ubuntu.com/security/notices/USN-6688-1");
  script_set_attribute(attribute:"solution", value:
"Update the affected kernel package.");
  script_set_cvss_base_vector("CVSS2#AV:L/AC:L/Au:S/C:C/I:C/A:C");
  script_set_cvss_temporal_vector("CVSS2#E:H/RL:OF/RC:C");
  script_set_cvss3_base_vector("CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H");
  script_set_cvss3_temporal_vector("CVSS:3.0/E:H/RL:O/RC:C");
  script_set_attribute(attribute:"cvss_score_source", value:"CVE-2024-26599");

  script_set_attribute(attribute:"exploitability_ease", value:"Exploits are available");
  script_set_attribute(attribute:"exploit_available", value:"true");
  script_set_attribute(attribute:"exploited_by_malware", value:"true");

  script_set_attribute(attribute:"vuln_publication_date", value:"2023/10/23");
  script_set_attribute(attribute:"patch_publication_date", value:"2024/03/11");
  script_set_attribute(attribute:"plugin_publication_date", value:"2024/03/11");

  script_set_attribute(attribute:"plugin_type", value:"local");
  script_set_attribute(attribute:"cpe", value:"cpe:/o:canonical:ubuntu_linux:22.04:-:lts");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:canonical:ubuntu_linux:linux-image-6.1.0-1035-oem");
  script_set_attribute(attribute:"generated_plugin", value:"current");
  script_end_attributes();

  script_category(ACT_GATHER_INFO);
  script_family(english:"Ubuntu Local Security Checks");

  script_copyright(english:"Ubuntu Security Notice (C) 2024 Canonical, Inc. / NASL script (C) 2024 and is owned by Tenable, Inc. or an Affiliate thereof.");

  script_dependencies("ssh_get_info.nasl", "linux_alt_patch_detect.nasl");
  script_require_keys("Host/cpu", "Host/Ubuntu", "Host/Ubuntu/release", "Host/Debian/dpkg-l");

  exit(0);
}

include('debian_package.inc');
include('ksplice.inc');

if ( ! get_kb_item('Host/local_checks_enabled') ) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);
var os_release = get_kb_item('Host/Ubuntu/release');
if ( isnull(os_release) ) audit(AUDIT_OS_NOT, 'Ubuntu');
os_release = chomp(os_release);
if (! ('22.04' >< os_release)) audit(AUDIT_OS_NOT, 'Ubuntu 22.04', 'Ubuntu ' + os_release);
if ( ! get_kb_item('Host/Debian/dpkg-l') ) audit(AUDIT_PACKAGE_LIST_MISSING);

var cpu = get_kb_item('Host/cpu');
if (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);
if ('x86_64' >!< cpu && cpu !~ "^i[3-6]86$" && 's390' >!< cpu && 'aarch64' >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, 'Ubuntu', cpu);

var kernel_mappings = {
  '22.04': {
    '6.1.0': {
      'oem': '6.1.0-1035'
    }
  }
};

var host_kernel_release = get_kb_item('Host/uptrack-uname-r');
if (empty_or_null(host_kernel_release)) host_kernel_release = get_kb_item_or_exit('Host/uname-r');
var host_kernel_base_version = get_kb_item_or_exit('Host/Debian/kernel-base-version');
var host_kernel_type = get_kb_item_or_exit('Host/Debian/kernel-type');
if(empty_or_null(kernel_mappings[os_release][host_kernel_base_version][host_kernel_type])) audit(AUDIT_INST_VER_NOT_VULN, 'kernel ' + host_kernel_release);

var extra = '';
var kernel_fixed_version = kernel_mappings[os_release][host_kernel_base_version][host_kernel_type] + "-" + host_kernel_type;
if (deb_ver_cmp(ver1:host_kernel_release, ver2:kernel_fixed_version) < 0)
{
  extra = extra + 'Running Kernel level of ' + host_kernel_release + ' does not meet the minimum fixed level of ' + kernel_fixed_version + ' for this advisory.\n\n';
}
  else
{
  audit(AUDIT_PATCH_INSTALLED, 'Kernel package for USN-6688-1');
}

if (get_one_kb_item('Host/ksplice/kernel-cves'))
{
  var cve_list = make_list('CVE-2023-5633', 'CVE-2023-6610', 'CVE-2023-46838', 'CVE-2023-50431', 'CVE-2023-52436', 'CVE-2023-52438', 'CVE-2023-52439', 'CVE-2023-52443', 'CVE-2023-52444', 'CVE-2023-52445', 'CVE-2023-52447', 'CVE-2023-52448', 'CVE-2023-52449', 'CVE-2023-52451', 'CVE-2023-52454', 'CVE-2023-52456', 'CVE-2023-52457', 'CVE-2023-52458', 'CVE-2023-52462', 'CVE-2023-52463', 'CVE-2023-52464', 'CVE-2023-52467', 'CVE-2023-52469', 'CVE-2023-52470', 'CVE-2023-52583', 'CVE-2023-52584', 'CVE-2023-52587', 'CVE-2023-52588', 'CVE-2023-52589', 'CVE-2023-52593', 'CVE-2023-52594', 'CVE-2023-52595', 'CVE-2023-52597', 'CVE-2023-52598', 'CVE-2023-52599', 'CVE-2023-52600', 'CVE-2023-52601', 'CVE-2023-52602', 'CVE-2023-52603', 'CVE-2023-52604', 'CVE-2023-52605', 'CVE-2023-52606', 'CVE-2023-52607', 'CVE-2024-0340', 'CVE-2024-1085', 'CVE-2024-1086', 'CVE-2024-23849', 'CVE-2024-24860', 'CVE-2024-26581', 'CVE-2024-26588', 'CVE-2024-26589', 'CVE-2024-26591', 'CVE-2024-26592', 'CVE-2024-26594', 'CVE-2024-26597', 'CVE-2024-26598', 'CVE-2024-26599', 'CVE-2024-26600', 'CVE-2024-26601', 'CVE-2024-26624', 'CVE-2024-26625', 'CVE-2024-26627', 'CVE-2024-26628');
  if (ksplice_cves_check(cve_list))
  {
    audit(AUDIT_PATCH_INSTALLED, 'KSplice hotfix for USN-6688-1');
  }
  else
  {
    extra = extra + ksplice_reporting_text();
  }
}
if (extra) {
  security_report_v4(
    port       : 0,
    severity   : SECURITY_WARNING,
    extra      : extra
  );
  exit(0);
}