SUSE SLES15 / openSUSE 15 Security Update : kernel (SUSE-SU-2024:1490-1)

#%NASL_MIN_LEVEL 80900
##
# (C) Tenable, Inc.
#
# The package checks in this plugin were extracted from
# SUSE update advisory SUSE-SU-2024:1490-1. The text itself
# is copyright (C) SUSE.
##

include('compat.inc');

if (description)
{
  script_id(194976);
  script_version("1.0");
  script_set_attribute(attribute:"plugin_modification_date", value:"2024/05/04");

  script_cve_id(
    "CVE-2021-46925",
    "CVE-2021-46926",
    "CVE-2021-46927",
    "CVE-2021-46929",
    "CVE-2021-46930",
    "CVE-2021-46931",
    "CVE-2021-46933",
    "CVE-2021-46936",
    "CVE-2021-47082",
    "CVE-2021-47087",
    "CVE-2021-47091",
    "CVE-2021-47093",
    "CVE-2021-47094",
    "CVE-2021-47095",
    "CVE-2021-47096",
    "CVE-2021-47097",
    "CVE-2021-47098",
    "CVE-2021-47099",
    "CVE-2021-47100",
    "CVE-2021-47101",
    "CVE-2021-47102",
    "CVE-2021-47104",
    "CVE-2021-47105",
    "CVE-2021-47107",
    "CVE-2021-47108",
    "CVE-2021-47181",
    "CVE-2021-47182",
    "CVE-2021-47183",
    "CVE-2021-47185",
    "CVE-2021-47189",
    "CVE-2022-4744",
    "CVE-2022-48626",
    "CVE-2022-48629",
    "CVE-2022-48630",
    "CVE-2023-0160",
    "CVE-2023-4881",
    "CVE-2023-6356",
    "CVE-2023-6535",
    "CVE-2023-6536",
    "CVE-2023-7042",
    "CVE-2023-7192",
    "CVE-2023-28746",
    "CVE-2023-35827",
    "CVE-2023-52447",
    "CVE-2023-52450",
    "CVE-2023-52453",
    "CVE-2023-52454",
    "CVE-2023-52469",
    "CVE-2023-52470",
    "CVE-2023-52474",
    "CVE-2023-52476",
    "CVE-2023-52477",
    "CVE-2023-52481",
    "CVE-2023-52484",
    "CVE-2023-52486",
    "CVE-2023-52488",
    "CVE-2023-52492",
    "CVE-2023-52493",
    "CVE-2023-52494",
    "CVE-2023-52497",
    "CVE-2023-52500",
    "CVE-2023-52501",
    "CVE-2023-52502",
    "CVE-2023-52503",
    "CVE-2023-52504",
    "CVE-2023-52507",
    "CVE-2023-52508",
    "CVE-2023-52509",
    "CVE-2023-52510",
    "CVE-2023-52511",
    "CVE-2023-52513",
    "CVE-2023-52515",
    "CVE-2023-52517",
    "CVE-2023-52518",
    "CVE-2023-52519",
    "CVE-2023-52520",
    "CVE-2023-52523",
    "CVE-2023-52524",
    "CVE-2023-52525",
    "CVE-2023-52528",
    "CVE-2023-52529",
    "CVE-2023-52532",
    "CVE-2023-52561",
    "CVE-2023-52563",
    "CVE-2023-52564",
    "CVE-2023-52566",
    "CVE-2023-52567",
    "CVE-2023-52569",
    "CVE-2023-52574",
    "CVE-2023-52575",
    "CVE-2023-52576",
    "CVE-2023-52582",
    "CVE-2023-52583",
    "CVE-2023-52587",
    "CVE-2023-52591",
    "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-2023-52608",
    "CVE-2023-52612",
    "CVE-2023-52615",
    "CVE-2023-52617",
    "CVE-2023-52619",
    "CVE-2023-52621",
    "CVE-2023-52623",
    "CVE-2023-52627",
    "CVE-2023-52628",
    "CVE-2023-52632",
    "CVE-2023-52636",
    "CVE-2023-52637",
    "CVE-2023-52639",
    "CVE-2024-0841",
    "CVE-2024-2201",
    "CVE-2024-22099",
    "CVE-2024-23307",
    "CVE-2024-23850",
    "CVE-2024-25739",
    "CVE-2024-25742",
    "CVE-2024-26599",
    "CVE-2024-26600",
    "CVE-2024-26602",
    "CVE-2024-26612",
    "CVE-2024-26614",
    "CVE-2024-26620",
    "CVE-2024-26627",
    "CVE-2024-26629",
    "CVE-2024-26642",
    "CVE-2024-26645",
    "CVE-2024-26646",
    "CVE-2024-26651",
    "CVE-2024-26654",
    "CVE-2024-26659",
    "CVE-2024-26660",
    "CVE-2024-26664",
    "CVE-2024-26667",
    "CVE-2024-26670",
    "CVE-2024-26680",
    "CVE-2024-26681",
    "CVE-2024-26684",
    "CVE-2024-26685",
    "CVE-2024-26689",
    "CVE-2024-26695",
    "CVE-2024-26696",
    "CVE-2024-26697",
    "CVE-2024-26704",
    "CVE-2024-26717",
    "CVE-2024-26718",
    "CVE-2024-26722",
    "CVE-2024-26727",
    "CVE-2024-26733",
    "CVE-2024-26736",
    "CVE-2024-26737",
    "CVE-2024-26743",
    "CVE-2024-26744",
    "CVE-2024-26745",
    "CVE-2024-26747",
    "CVE-2024-26749",
    "CVE-2024-26751",
    "CVE-2024-26754",
    "CVE-2024-26760",
    "CVE-2024-26763",
    "CVE-2024-26766",
    "CVE-2024-26769",
    "CVE-2024-26771",
    "CVE-2024-26776",
    "CVE-2024-26779",
    "CVE-2024-26787",
    "CVE-2024-26790",
    "CVE-2024-26793",
    "CVE-2024-26798",
    "CVE-2024-26805",
    "CVE-2024-26807",
    "CVE-2024-26848"
  );
  script_xref(name:"SuSE", value:"SUSE-SU-2024:1490-1");

  script_name(english:"SUSE SLES15 / openSUSE 15 Security Update : kernel (SUSE-SU-2024:1490-1)");

  script_set_attribute(attribute:"synopsis", value:
"The remote SUSE host is missing one or more security updates.");
  script_set_attribute(attribute:"description", value:
"The remote SUSE Linux SLES15 / SLES_SAP15 / openSUSE 15 host has packages installed that are affected by multiple
vulnerabilities as referenced in the SUSE-SU-2024:1490-1 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: net/smc: fix kernel panic caused by
    race of smc_sock A crash occurs when smc_cdc_tx_handler() tries to access smc_sock but smc_release() has
    already freed it. [ 4570.695099] BUG: unable to handle page fault for address: 000000002eae9e88 [
    4570.696048] #PF: supervisor write access in kernel mode [ 4570.696728] #PF: error_code(0x0002) - not-
    present page [ 4570.697401] PGD 0 P4D 0 [ 4570.697716] Oops: 0002 [#1] PREEMPT SMP NOPTI [ 4570.698228]
    CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.16.0-rc4+ #111 [ 4570.699013] Hardware name: Alibaba Cloud
    Alibaba Cloud ECS, BIOS 8c24b4c 04/0 [ 4570.699933] RIP: 0010:_raw_spin_lock+0x1a/0x30 <...> [
    4570.711446] Call Trace: [ 4570.711746] <IRQ> [ 4570.711992] smc_cdc_tx_handler+0x41/0xc0 [ 4570.712470]
    smc_wr_tx_tasklet_fn+0x213/0x560 [ 4570.712981] ? smc_cdc_tx_dismisser+0x10/0x10 [ 4570.713489]
    tasklet_action_common.isra.17+0x66/0x140 [ 4570.714083] __do_softirq+0x123/0x2f4 [ 4570.714521]
    irq_exit_rcu+0xc4/0xf0 [ 4570.714934] common_interrupt+0xba/0xe0 Though smc_cdc_tx_handler() checked the
    existence of smc connection, smc_release() may have already dismissed and released the smc socket before
    smc_cdc_tx_handler() further visits it. smc_cdc_tx_handler() |smc_release() if (!conn) | |
    |smc_cdc_tx_dismiss_slots() | smc_cdc_tx_dismisser() | |sock_put(&smc->sk) <- last sock_put, | smc_sock
    freed bh_lock_sock(&smc->sk) (panic) | To make sure we won't receive any CDC messages after we free the
    smc_sock, add a refcount on the smc_connection for inflight CDC message(posted to the QP but haven't
    received related CQE), and don't release the smc_connection until all the inflight CDC messages haven been
    done, for both success or failed ones. Using refcount on CDC messages brings another problem: when the
    link is going to be destroyed, smcr_link_clear() will reset the QP, which then remove all the pending CQEs
    related to the QP in the CQ. To make sure all the CQEs will always come back so the refcount on the
    smc_connection can always reach 0, smc_ib_modify_qp_reset() was replaced by smc_ib_modify_qp_error(). And
    remove the timeout in smc_wr_tx_wait_no_pending_sends() since we need to wait for all pending WQEs done,
    or we may encounter use-after- free when handling CQEs. For IB device removal routine, we need to wait for
    all the QPs on that device been destroyed before we can destroy CQs on the device, or the refcount on
    smc_connection won't reach 0 and smc_sock cannot be released. (CVE-2021-46925)

  - In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: intel-sdw-acpi: harden
    detection of controller The existing code currently sets a pointer to an ACPI handle before checking that
    it's actually a SoundWire controller. This can lead to issues where the graph walk continues and
    eventually fails, but the pointer was set already. This patch changes the logic so that the information
    provided to the caller is set when a controller is found. (CVE-2021-46926)

  - In the Linux kernel, the following vulnerability has been resolved: nitro_enclaves: Use
    get_user_pages_unlocked() call to handle mmap assert After commit 5b78ed24e8ec (mm/pagemap: add
    mmap_assert_locked() annotations to find_vma*()), the call to get_user_pages() will trigger the mmap
    assert. static inline void mmap_assert_locked(struct mm_struct *mm) { lockdep_assert_held(&mm->mmap_lock);
    VM_BUG_ON_MM(!rwsem_is_locked(&mm->mmap_lock), mm); } [ 62.521410] kernel BUG at
    include/linux/mmap_lock.h:156! ........................................................... [ 62.538938]
    RIP: 0010:find_vma+0x32/0x80 ........................................................... [ 62.605889] Call
    Trace: [ 62.608502] <TASK> [ 62.610956] ? lock_timer_base+0x61/0x80 [ 62.614106] find_extend_vma+0x19/0x80
    [ 62.617195] __get_user_pages+0x9b/0x6a0 [ 62.620356] __gup_longterm_locked+0x42d/0x450 [ 62.623721] ?
    finish_wait+0x41/0x80 [ 62.626748] ? __kmalloc+0x178/0x2f0 [ 62.629768]
    ne_set_user_memory_region_ioctl.isra.0+0x225/0x6a0 [nitro_enclaves] [ 62.635776]
    ne_enclave_ioctl+0x1cf/0x6d7 [nitro_enclaves] [ 62.639541] __x64_sys_ioctl+0x82/0xb0 [ 62.642620]
    do_syscall_64+0x3b/0x90 [ 62.645642] entry_SYSCALL_64_after_hwframe+0x44/0xae Use
    get_user_pages_unlocked() when setting the enclave memory regions. That's a similar pattern as
    mmap_read_lock() used together with get_user_pages(). (CVE-2021-46927)

  - In the Linux kernel, the following vulnerability has been resolved: sctp: use call_rcu to free endpoint
    This patch is to delay the endpoint free by calling call_rcu() to fix another use-after-free issue in
    sctp_sock_dump(): BUG: KASAN: use-after-free in __lock_acquire+0x36d9/0x4c20 Call Trace:
    __lock_acquire+0x36d9/0x4c20 kernel/locking/lockdep.c:3218 lock_acquire+0x1ed/0x520
    kernel/locking/lockdep.c:3844 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]
    _raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168 spin_lock_bh include/linux/spinlock.h:334
    [inline] __lock_sock+0x203/0x350 net/core/sock.c:2253 lock_sock_nested+0xfe/0x120 net/core/sock.c:2774
    lock_sock include/net/sock.h:1492 [inline] sctp_sock_dump+0x122/0xb20 net/sctp/diag.c:324
    sctp_for_each_transport+0x2b5/0x370 net/sctp/socket.c:5091 sctp_diag_dump+0x3ac/0x660 net/sctp/diag.c:527
    __inet_diag_dump+0xa8/0x140 net/ipv4/inet_diag.c:1049 inet_diag_dump+0x9b/0x110 net/ipv4/inet_diag.c:1065
    netlink_dump+0x606/0x1080 net/netlink/af_netlink.c:2244 __netlink_dump_start+0x59a/0x7c0
    net/netlink/af_netlink.c:2352 netlink_dump_start include/linux/netlink.h:216 [inline]
    inet_diag_handler_cmd+0x2ce/0x3f0 net/ipv4/inet_diag.c:1170 __sock_diag_cmd net/core/sock_diag.c:232
    [inline] sock_diag_rcv_msg+0x31d/0x410 net/core/sock_diag.c:263 netlink_rcv_skb+0x172/0x440
    net/netlink/af_netlink.c:2477 sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:274 This issue occurs when asoc
    is peeled off and the old sk is freed after getting it by asoc->base.sk and before calling lock_sock(sk).
    To prevent the sk free, as a holder of the sk, ep should be alive when calling lock_sock(). This patch
    uses call_rcu() and moves sock_put and ep free into sctp_endpoint_destroy_rcu(), so that it's safe to try
    to hold the ep under rcu_read_lock in sctp_transport_traverse_process(). If sctp_endpoint_hold() returns
    true, it means this ep is still alive and we have held it and can continue to dump it; If it returns
    false, it means this ep is dead and can be freed after rcu_read_unlock, and we should skip it. In
    sctp_sock_dump(), after locking the sk, if this ep is different from tsp->asoc->ep, it means during this
    dumping, this asoc was peeled off before calling lock_sock(), and the sk should be skipped; If this ep is
    the same with tsp->asoc->ep, it means no peeloff happens on this asoc, and due to lock_sock, no peeloff
    will happen either until release_sock. Note that delaying endpoint free won't delay the port release, as
    the port release happens in sctp_endpoint_destroy() before calling call_rcu(). Also, freeing endpoint by
    call_rcu() makes it safe to access the sk by asoc->base.sk in sctp_assocs_seq_show() and sctp_rcv().
    Thanks Jones to bring this issue up. v1->v2: - improve the changelog. - add kfree(ep) into
    sctp_endpoint_destroy_rcu(), as Jakub noticed. (CVE-2021-46929)

  - In the Linux kernel, the following vulnerability has been resolved: usb: mtu3: fix list_head check warning
    This is caused by uninitialization of list_head. BUG: KASAN: use-after-free in
    __list_del_entry_valid+0x34/0xe4 Call trace: dump_backtrace+0x0/0x298 show_stack+0x24/0x34
    dump_stack+0x130/0x1a8 print_address_description+0x88/0x56c __kasan_report+0x1b8/0x2a0
    kasan_report+0x14/0x20 __asan_load8+0x9c/0xa0 __list_del_entry_valid+0x34/0xe4
    mtu3_req_complete+0x4c/0x300 [mtu3] mtu3_gadget_stop+0x168/0x448 [mtu3]
    usb_gadget_unregister_driver+0x204/0x3a0 unregister_gadget_item+0x44/0xa4 (CVE-2021-46930)

  - In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Wrap the tx reporter dump
    callback to extract the sq Function mlx5e_tx_reporter_dump_sq() casts its void * argument to struct
    mlx5e_txqsq *, but in TX-timeout-recovery flow the argument is actually of type struct
    mlx5e_tx_timeout_ctx *. mlx5_core 0000:08:00.1 enp8s0f1: TX timeout detected mlx5_core 0000:08:00.1
    enp8s0f1: TX timeout on queue: 1, SQ: 0x11ec, CQ: 0x146d, SQ Cons: 0x0 SQ Prod: 0x1, usecs since last
    trans: 21565000 BUG: stack guard page was hit at 0000000093f1a2de (stack is
    00000000b66ea0dc..000000004d932dae) kernel stack overflow (page fault): 0000 [#1] SMP NOPTI CPU: 5 PID: 95
    Comm: kworker/u20:1 Tainted: G W OE 5.13.0_mlnx #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
    BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5e mlx5e_tx_timeout_work
    [mlx5_core] RIP: 0010:mlx5e_tx_reporter_dump_sq+0xd3/0x180 [mlx5_core] Call Trace:
    mlx5e_tx_reporter_dump+0x43/0x1c0 [mlx5_core] devlink_health_do_dump.part.91+0x71/0xd0
    devlink_health_report+0x157/0x1b0 mlx5e_reporter_tx_timeout+0xb9/0xf0 [mlx5_core] ?
    mlx5e_tx_reporter_err_cqe_recover+0x1d0/0x1d0 [mlx5_core] ? mlx5e_health_queue_dump+0xd0/0xd0 [mlx5_core]
    ? update_load_avg+0x19b/0x550 ? set_next_entity+0x72/0x80 ? pick_next_task_fair+0x227/0x340 ?
    finish_task_switch+0xa2/0x280 mlx5e_tx_timeout_work+0x83/0xb0 [mlx5_core] process_one_work+0x1de/0x3a0
    worker_thread+0x2d/0x3c0 ? process_one_work+0x3a0/0x3a0 kthread+0x115/0x130 ? kthread_park+0x90/0x90
    ret_from_fork+0x1f/0x30 --[ end trace 51ccabea504edaff ]--- RIP: 0010:mlx5e_tx_reporter_dump_sq+0xd3/0x180
    PKRU: 55555554 Kernel panic - not syncing: Fatal exception Kernel Offset: disabled end Kernel panic - not
    syncing: Fatal exception To fix this bug add a wrapper for mlx5e_tx_reporter_dump_sq() which extracts the
    sq from struct mlx5e_tx_timeout_ctx and set it as the TX-timeout-recovery flow dump callback.
    (CVE-2021-46931)

  - In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Clear ffs_eventfd
    in ffs_data_clear. ffs_data_clear is indirectly called from both ffs_fs_kill_sb and ffs_ep0_release, so it
    ends up being called twice when userland closes ep0 and then unmounts f_fs. If userland provided an
    eventfd along with function's USB descriptors, it ends up calling eventfd_ctx_put as many times, causing a
    refcount underflow. NULL-ify ffs_eventfd to prevent these extraneous eventfd_ctx_put calls. Also, set
    epfiles to NULL right after de-allocating it, for readability. For completeness, ffs_data_clear actually
    ends up being called thrice, the last call being before the whole ffs structure gets freed, so when this
    specific sequence happens there is a second underflow happening (but not being reported):
    /sys/kernel/debug/tracing# modprobe usb_f_fs /sys/kernel/debug/tracing# echo ffs_data_clear >
    set_ftrace_filter /sys/kernel/debug/tracing# echo function > current_tracer /sys/kernel/debug/tracing#
    echo 1 > tracing_on (setup gadget, run and kill function userland process, teardown gadget)
    /sys/kernel/debug/tracing# echo 0 > tracing_on /sys/kernel/debug/tracing# cat trace smartcard-openp-436
    [000] ..... 1946.208786: ffs_data_clear <-ffs_data_closed smartcard-openp-431 [000] ..... 1946.279147:
    ffs_data_clear <-ffs_data_closed smartcard-openp-431 [000] .n... 1946.905512: ffs_data_clear
    <-ffs_data_put Warning output corresponding to above trace: [ 1946.284139] WARNING: CPU: 0 PID: 431 at
    lib/refcount.c:28 refcount_warn_saturate+0x110/0x15c [ 1946.293094] refcount_t: underflow; use-after-free.
    [ 1946.298164] Modules linked in: usb_f_ncm(E) u_ether(E) usb_f_fs(E) hci_uart(E) btqca(E) btrtl(E)
    btbcm(E) btintel(E) bluetooth(E) nls_ascii(E) nls_cp437(E) vfat(E) fat(E) bcm2835_v4l2(CE)
    bcm2835_mmal_vchiq(CE) videobuf2_vmalloc(E) videobuf2_memops(E) sha512_generic(E) videobuf2_v4l2(E)
    sha512_arm(E) videobuf2_common(E) videodev(E) cpufreq_dt(E) snd_bcm2835(CE) brcmfmac(E) mc(E) vc4(E)
    ctr(E) brcmutil(E) snd_soc_core(E) snd_pcm_dmaengine(E) drbg(E) snd_pcm(E) snd_timer(E) snd(E)
    soundcore(E) drm_kms_helper(E) cec(E) ansi_cprng(E) rc_core(E) syscopyarea(E) raspberrypi_cpufreq(E)
    sysfillrect(E) sysimgblt(E) cfg80211(E) max17040_battery(OE) raspberrypi_hwmon(E) fb_sys_fops(E)
    regmap_i2c(E) ecdh_generic(E) rfkill(E) ecc(E) bcm2835_rng(E) rng_core(E) vchiq(CE) leds_gpio(E)
    libcomposite(E) fuse(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E)
    jbd2(E) crc32c_generic(E) sdhci_iproc(E) sdhci_pltfm(E) sdhci(E) [ 1946.399633] CPU: 0 PID: 431 Comm:
    smartcard-openp Tainted: G C OE 5.15.0-1-rpi #1 Debian 5.15.3-1 [ 1946.417950] Hardware name: BCM2835 [
    1946.425442] Backtrace: [ 1946.432048] [<c08d60a0>] (dump_backtrace) from [<c08d62ec>]
    (show_stack+0x20/0x24) [ 1946.448226] r7:00000009 r6:0000001c r5:c04a948c r4:c0a64e2c [ 1946.458412]
    [<c08d62cc>] (show_stack) from [<c08d9ae0>] (dump_stack+0x28/0x30) [ 1946.470380] [<c08d9ab8>]
    (dump_stack) from [<c0123500>] (__warn+0xe8/0x154) [ 1946.482067] r5:c04a948c r4:c0a71dc8 [ 1946.490184]
    [<c0123418>] (__warn) from [<c08d6948>] (warn_slowpath_fmt+0xa0/0xe4) [ 1946.506758] r7:00000009
    r6:0000001c r5:c0a71dc8 r4:c0a71e04 [ 1946.517070] [<c08d68ac>] (warn_slowpath_fmt) from [<c04a948c>]
    (refcount_warn_saturate+0x110/0x15c) [ 1946.535309] r8:c0100224 r7:c0dfcb84 r6:ffffffff r5:c3b84c00
    r4:c24a17c0 [ 1946.546708] [<c04a937c>] (refcount_warn_saturate) from [<c0380134>]
    (eventfd_ctx_put+0x48/0x74) [ 1946.564476] [<c03800ec>] (eventfd_ctx_put) from [<bf5464e8>]
    (ffs_data_clear+0xd0/0x118 [usb_f_fs]) [ 1946.582664] r5:c3b84c00 r4:c2695b00 [ 1946.590668] [<bf546418>]
    (ffs_data_clear [usb_f_fs]) from [<bf547cc0>] (ffs_data_closed+0x9c/0x150 [usb_f_fs]) [ 1946.609608]
    r5:bf54d014 r4:c2695b00 [ 1946.617522] [<bf547c24>] (ffs_data_closed [usb_f_fs]) from [<bf547da0>]
    (ffs_fs_kill_sb+0x2c/0x30 [usb_f_fs]) [ 1946.636217] r7:c0dfcb ---truncated--- (CVE-2021-46933)

  - In the Linux kernel, the following vulnerability has been resolved: net: fix use-after-free in
    tw_timer_handler A real world panic issue was found as follow in Linux 5.4. BUG: unable to handle page
    fault for address: ffffde49a863de28 PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0 RIP:
    0010:tw_timer_handler+0x20/0x40 Call Trace: <IRQ> call_timer_fn+0x2b/0x120 run_timer_softirq+0x1ef/0x450
    __do_softirq+0x10d/0x2b8 irq_exit+0xc7/0xd0 smp_apic_timer_interrupt+0x68/0x120
    apic_timer_interrupt+0xf/0x20 This issue was also reported since 2017 in the thread [1], unfortunately,
    the issue was still can be reproduced after fixing DCCP. The ipv4_mib_exit_net is called before
    tcp_sk_exit_batch when a net namespace is destroyed since tcp_sk_ops is registered befrore ipv4_mib_ops,
    which means tcp_sk_ops is in the front of ipv4_mib_ops in the list of pernet_list. There will be a use-
    after-free on net->mib.net_statistics in tw_timer_handler after ipv4_mib_exit_net if there are some
    inflight time-wait timers. This bug is not introduced by commit f2bf415cfed7 (mib: add net to
    NET_ADD_STATS_BH) since the net_statistics is a global variable instead of dynamic allocation and
    freeing. Actually, commit 61a7e26028b9 (mib: put net statistics on struct net) introduces the bug since
    it put net statistics on struct net and free it when net namespace is destroyed. Moving init_ipv4_mibs()
    to the front of tcp_init() to fix this bug and replace pr_crit() with panic() since continuing is
    meaningless when init_ipv4_mibs() fails. [1] https://groups.google.com/g/syzkaller/c/p1tn-
    _Kc6l4/m/smuL_FMAAgAJ?pli=1 (CVE-2021-46936)

  - In the Linux kernel, the following vulnerability has been resolved: tun: avoid double free in
    tun_free_netdev Avoid double free in tun_free_netdev() by moving the dev->tstats and tun->security allocs
    to a new ndo_init routine (tun_net_init()) that will be called by register_netdevice(). ndo_init is paired
    with the desctructor (tun_free_netdev()), so if there's an error in register_netdevice() the destructor
    will handle the frees. BUG: KASAN: double-free or invalid-free in selinux_tun_dev_free_security+0x1a/0x20
    security/selinux/hooks.c:5605 CPU: 0 PID: 25750 Comm: syz-executor416 Not tainted 5.16.0-rc2-syzk #1
    Hardware name: Red Hat KVM, BIOS Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline]
    dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106 print_address_description.constprop.9+0x28/0x160
    mm/kasan/report.c:247 kasan_report_invalid_free+0x55/0x80 mm/kasan/report.c:372 ____kasan_slab_free
    mm/kasan/common.c:346 [inline] __kasan_slab_free+0x107/0x120 mm/kasan/common.c:374 kasan_slab_free
    include/linux/kasan.h:235 [inline] slab_free_hook mm/slub.c:1723 [inline] slab_free_freelist_hook
    mm/slub.c:1749 [inline] slab_free mm/slub.c:3513 [inline] kfree+0xac/0x2d0 mm/slub.c:4561
    selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605
    security_tun_dev_free_security+0x4f/0x90 security/security.c:2342 tun_free_netdev+0xe6/0x150
    drivers/net/tun.c:2215 netdev_run_todo+0x4df/0x840 net/core/dev.c:10627 rtnl_unlock+0x13/0x20
    net/core/rtnetlink.c:112 __tun_chr_ioctl+0x80c/0x2870 drivers/net/tun.c:3302 tun_chr_ioctl+0x2f/0x40
    drivers/net/tun.c:3311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline]
    __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860 do_syscall_x64
    arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x44/0xae (CVE-2021-47082)

  - In the Linux kernel, the following vulnerability has been resolved: tee: optee: Fix incorrect page free
    bug Pointer to the allocated pages (struct page *page) has already progressed towards the end of
    allocation. It is incorrect to perform __free_pages(page, order) using this pointer as we would free any
    arbitrary pages. Fix this by stop modifying the page pointer. (CVE-2021-47087)

  - In the Linux kernel, the following vulnerability has been resolved: mac80211: fix locking in
    ieee80211_start_ap error path We need to hold the local->mtx to release the channel context, as even
    encoded by the lockdep_assert_held() there. Fix it. (CVE-2021-47091)

  - In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel_pmc_core: fix
    memleak on registration failure In case device registration fails during module initialisation, the
    platform device structure needs to be freed using platform_device_put() to properly free all resources
    (e.g. the device name). (CVE-2021-47093)

  - In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Don't advance iterator
    after restart due to yielding After dropping mmu_lock in the TDP MMU, restart the iterator during
    tdp_iter_next() and do not advance the iterator. Advancing the iterator results in skipping the top-level
    SPTE and all its children, which is fatal if any of the skipped SPTEs were not visited before yielding.
    When zapping all SPTEs, i.e. when min_level == root_level, restarting the iter and then invoking
    tdp_iter_next() is always fatal if the current gfn has as a valid SPTE, as advancing the iterator results
    in try_step_side() skipping the current gfn, which wasn't visited before yielding. Sprinkle WARNs on
    iter->yielded being true in various helpers that are often used in conjunction with yielding, and tag the
    helper with __must_check to reduce the probabily of improper usage. Failing to zap a top-level SPTE
    manifests in one of two ways. If a valid SPTE is skipped by both kvm_tdp_mmu_zap_all() and
    kvm_tdp_mmu_put_root(), the shadow page will be leaked and KVM will WARN accordingly. WARNING: CPU: 1 PID:
    3509 at arch/x86/kvm/mmu/tdp_mmu.c:46 [kvm] RIP: 0010:kvm_mmu_uninit_tdp_mmu+0x3e/0x50 [kvm] Call Trace:
    <TASK> kvm_arch_destroy_vm+0x130/0x1b0 [kvm] kvm_destroy_vm+0x162/0x2a0 [kvm] kvm_vcpu_release+0x34/0x60
    [kvm] __fput+0x82/0x240 task_work_run+0x5c/0x90 do_exit+0x364/0xa10 ? futex_unqueue+0x38/0x60
    do_group_exit+0x33/0xa0 get_signal+0x155/0x850 arch_do_signal_or_restart+0xed/0x750
    exit_to_user_mode_prepare+0xc5/0x120 syscall_exit_to_user_mode+0x1d/0x40 do_syscall_64+0x48/0xc0
    entry_SYSCALL_64_after_hwframe+0x44/0xae If kvm_tdp_mmu_zap_all() skips a gfn/SPTE but that SPTE is then
    zapped by kvm_tdp_mmu_put_root(), KVM triggers a use-after-free in the form of marking a struct page as
    dirty/accessed after it has been put back on the free list. This directly triggers a WARN due to
    encountering a page with page_count() == 0, but it can also lead to data corruption and additional errors
    in the kernel. WARNING: CPU: 7 PID: 1995658 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:171 RIP:
    0010:kvm_is_zone_device_pfn.part.0+0x9e/0xd0 [kvm] Call Trace: <TASK> kvm_set_pfn_dirty+0x120/0x1d0 [kvm]
    __handle_changed_spte+0x92e/0xca0 [kvm] __handle_changed_spte+0x63c/0xca0 [kvm]
    __handle_changed_spte+0x63c/0xca0 [kvm] __handle_changed_spte+0x63c/0xca0 [kvm] zap_gfn_range+0x549/0x620
    [kvm] kvm_tdp_mmu_put_root+0x1b6/0x270 [kvm] mmu_free_root_page+0x219/0x2c0 [kvm]
    kvm_mmu_free_roots+0x1b4/0x4e0 [kvm] kvm_mmu_unload+0x1c/0xa0 [kvm] kvm_arch_destroy_vm+0x1f2/0x5c0 [kvm]
    kvm_put_kvm+0x3b1/0x8b0 [kvm] kvm_vcpu_release+0x4e/0x70 [kvm] __fput+0x1f7/0x8c0 task_work_run+0xf8/0x1a0
    do_exit+0x97b/0x2230 do_group_exit+0xda/0x2a0 get_signal+0x3be/0x1e50
    arch_do_signal_or_restart+0x244/0x17f0 exit_to_user_mode_prepare+0xcb/0x120
    syscall_exit_to_user_mode+0x1d/0x40 do_syscall_64+0x4d/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Note,
    the underlying bug existed even before commit 1af4a96025b3 (KVM: x86/mmu: Yield in TDU MMU iter even if
    no SPTES changed) moved calls to tdp_mmu_iter_cond_resched() to the beginning of loops, as KVM could
    still incorrectly advance past a top-level entry when yielding on a lower-level entry. But with respect to
    leaking shadow pages, the bug was introduced by yielding before processing the current gfn. Alternatively,
    tdp_mmu_iter_cond_resched() could simply fall through, or callers could jump to their retry label. The
    downside of that approach is that tdp_mmu_iter_cond_resched() _must_ be called before anything else in the
    loop, and there's no easy way to enfornce that requirement. Ideally, KVM would handling the cond_resched()
    fully within the iterator macro (the code is actually quite clean) and avoid this entire class of bugs,
    but that is extremely difficult do wh ---truncated--- (CVE-2021-47094)

  - In the Linux kernel, the following vulnerability has been resolved: ipmi: ssif: initialize
    ssif_info->client early During probe ssif_info->client is dereferenced in error path. However, it is set
    when some of the error checking has already been done. This causes following kernel crash if an error path
    is taken: [ 30.645593][ T674] ipmi_ssif 0-000e: ipmi_ssif: Not probing, Interface already present [
    30.657616][ T674] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000088 ...
    [ 30.657723][ T674] pc : __dev_printk+0x28/0xa0 [ 30.657732][ T674] lr : _dev_err+0x7c/0xa0 ... [
    30.657772][ T674] Call trace: [ 30.657775][ T674] __dev_printk+0x28/0xa0 [ 30.657778][ T674]
    _dev_err+0x7c/0xa0 [ 30.657781][ T674] ssif_probe+0x548/0x900 [ipmi_ssif
    62ce4b08badc1458fd896206d9ef69a3c31f3d3e] [ 30.657791][ T674] i2c_device_probe+0x37c/0x3c0 ... Initialize
    ssif_info->client before any error path can be taken. Clear i2c_client data in the error path to prevent
    the dangling pointer from leaking. (CVE-2021-47095)

  - In the Linux kernel, the following vulnerability has been resolved: ALSA: rawmidi - fix the uninitalized
    user_pversion The user_pversion was uninitialized for the user space file structure in the open function,
    because the file private structure use kmalloc for the allocation. The kernel ALSA sequencer code clears
    the file structure, so no additional fixes are required. BugLink: https://github.com/alsa-project/alsa-
    lib/issues/178 (CVE-2021-47096)

  - In the Linux kernel, the following vulnerability has been resolved: Input: elantech - fix stack out of
    bound access in elantech_change_report_id() The array param[] in elantech_change_report_id() must be at
    least 3 bytes, because elantech_read_reg_params() is calling ps2_command() with PSMOUSE_CMD_GETINFO, that
    is going to access 3 bytes from param[], but it's defined in the stack as an array of 2 bytes, therefore
    we have a potential stack out-of-bounds access here, also confirmed by KASAN: [ 6.512374] BUG: KASAN:
    stack-out-of-bounds in __ps2_command+0x372/0x7e0 [ 6.512397] Read of size 1 at addr ffff8881024d77c2 by
    task kworker/2:1/118 [ 6.512416] CPU: 2 PID: 118 Comm: kworker/2:1 Not tainted 5.13.0-22-generic
    #22+arighi20211110 [ 6.512428] Hardware name: LENOVO 20T8000QGE/20T8000QGE, BIOS R1AET32W (1.08 )
    08/14/2020 [ 6.512436] Workqueue: events_long serio_handle_event [ 6.512453] Call Trace: [ 6.512462]
    show_stack+0x52/0x58 [ 6.512474] dump_stack+0xa1/0xd3 [ 6.512487]
    print_address_description.constprop.0+0x1d/0x140 [ 6.512502] ? __ps2_command+0x372/0x7e0 [ 6.512516]
    __kasan_report.cold+0x7d/0x112 [ 6.512527] ? _raw_write_lock_irq+0x20/0xd0 [ 6.512539] ?
    __ps2_command+0x372/0x7e0 [ 6.512552] kasan_report+0x3c/0x50 [ 6.512564] __asan_load1+0x6a/0x70 [
    6.512575] __ps2_command+0x372/0x7e0 [ 6.512589] ? ps2_drain+0x240/0x240 [ 6.512601] ?
    dev_printk_emit+0xa2/0xd3 [ 6.512612] ? dev_vprintk_emit+0xc5/0xc5 [ 6.512621] ?
    __kasan_check_write+0x14/0x20 [ 6.512634] ? mutex_lock+0x8f/0xe0 [ 6.512643] ?
    __mutex_lock_slowpath+0x20/0x20 [ 6.512655] ps2_command+0x52/0x90 [ 6.512670]
    elantech_ps2_command+0x4f/0xc0 [psmouse] [ 6.512734] elantech_change_report_id+0x1e6/0x256 [psmouse] [
    6.512799] ? elantech_report_trackpoint.constprop.0.cold+0xd/0xd [psmouse] [ 6.512863] ?
    ps2_command+0x7f/0x90 [ 6.512877] elantech_query_info.cold+0x6bd/0x9ed [psmouse] [ 6.512943] ?
    elantech_setup_ps2+0x460/0x460 [psmouse] [ 6.513005] ? psmouse_reset+0x69/0xb0 [psmouse] [ 6.513064] ?
    psmouse_attr_set_helper+0x2a0/0x2a0 [psmouse] [ 6.513122] ? phys_pmd_init+0x30e/0x521 [ 6.513137]
    elantech_init+0x8a/0x200 [psmouse] [ 6.513200] ? elantech_init_ps2+0xf0/0xf0 [psmouse] [ 6.513249] ?
    elantech_query_info+0x440/0x440 [psmouse] [ 6.513296] ? synaptics_send_cmd+0x60/0x60 [psmouse] [ 6.513342]
    ? elantech_query_info+0x440/0x440 [psmouse] [ 6.513388] ? psmouse_try_protocol+0x11e/0x170 [psmouse] [
    6.513432] psmouse_extensions+0x65d/0x6e0 [psmouse] [ 6.513476] ? psmouse_try_protocol+0x170/0x170
    [psmouse] [ 6.513519] ? mutex_unlock+0x22/0x40 [ 6.513526] ? ps2_command+0x7f/0x90 [ 6.513536] ?
    psmouse_probe+0xa3/0xf0 [psmouse] [ 6.513580] psmouse_switch_protocol+0x27d/0x2e0 [psmouse] [ 6.513624]
    psmouse_connect+0x272/0x530 [psmouse] [ 6.513669] serio_driver_probe+0x55/0x70 [ 6.513679]
    really_probe+0x190/0x720 [ 6.513689] driver_probe_device+0x160/0x1f0 [ 6.513697]
    device_driver_attach+0x119/0x130 [ 6.513705] ? device_driver_attach+0x130/0x130 [ 6.513713]
    __driver_attach+0xe7/0x1a0 [ 6.513720] ? device_driver_attach+0x130/0x130 [ 6.513728]
    bus_for_each_dev+0xfb/0x150 [ 6.513738] ? subsys_dev_iter_exit+0x10/0x10 [ 6.513748] ?
    _raw_write_unlock_bh+0x30/0x30 [ 6.513757] driver_attach+0x2d/0x40 [ 6.513764]
    serio_handle_event+0x199/0x3d0 [ 6.513775] process_one_work+0x471/0x740 [ 6.513785]
    worker_thread+0x2d2/0x790 [ 6.513794] ? process_one_work+0x740/0x740 [ 6.513802] kthread+0x1b4/0x1e0 [
    6.513809] ? set_kthread_struct+0x80/0x80 [ 6.513816] ret_from_fork+0x22/0x30 [ 6.513832] The buggy address
    belongs to the page: [ 6.513838] page:00000000bc35e189 refcount:0 mapcount:0 mapping:0000000000000000
    index:0x0 pfn:0x1024d7 [ 6.513847] flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff) [ 6.513860]
    raw: 0 ---truncated--- (CVE-2021-47097)

  - In the Linux kernel, the following vulnerability has been resolved: hwmon: (lm90) Prevent integer
    overflow/underflow in hysteresis calculations Commit b50aa49638c7 (hwmon: (lm90) Prevent integer
    underflows of temperature calculations) addressed a number of underflow situations when writing
    temperature limits. However, it missed one situation, seen when an attempt is made to set the hysteresis
    value to MAX_LONG and the critical temperature limit is negative. Use clamp_val() when setting the
    hysteresis temperature to ensure that the provided value can never overflow or underflow. (CVE-2021-47098)

  - In the Linux kernel, the following vulnerability has been resolved: veth: ensure skb entering GRO are not
    cloned. After commit d3256efd8e8b (veth: allow enabling NAPI even without XDP), if GRO is enabled on a
    veth device and TSO is disabled on the peer device, TCP skbs will go through the NAPI callback. If there
    is no XDP program attached, the veth code does not perform any share check, and shared/cloned skbs could
    enter the GRO engine. Ignat reported a BUG triggered later-on due to the above condition: [ 53.970529][
    C1] kernel BUG at net/core/skbuff.c:3574! [ 53.981755][ C1] invalid opcode: 0000 [#1] PREEMPT SMP KASAN
    PTI [ 53.982634][ C1] CPU: 1 PID: 19 Comm: ksoftirqd/1 Not tainted 5.16.0-rc5+ #25 [ 53.982634][ C1]
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 [ 53.982634][ C1] RIP:
    0010:skb_shift+0x13ef/0x23b0 [ 53.982634][ C1] Code: ea 03 0f b6 04 02 48 89 fa 83 e2 07 38 d0 7f 08 84 c0
    0f 85 41 0c 00 00 41 80 7f 02 00 4d 8d b5 d0 00 00 00 0f 85 74 f5 ff ff <0f> 0b 4d 8d 77 20 be 04 00 00 00
    4c 89 44 24 78 4c 89 f7 4c 89 8c [ 53.982634][ C1] RSP: 0018:ffff8881008f7008 EFLAGS: 00010246 [
    53.982634][ C1] RAX: 0000000000000000 RBX: ffff8881180b4c80 RCX: 0000000000000000 [ 53.982634][ C1] RDX:
    0000000000000002 RSI: ffff8881180b4d3c RDI: ffff88810bc9cac2 [ 53.982634][ C1] RBP: ffff8881008f70b8 R08:
    ffff8881180b4cf4 R09: ffff8881180b4cf0 [ 53.982634][ C1] R10: ffffed1022999e5c R11: 0000000000000002 R12:
    0000000000000590 [ 53.982634][ C1] R13: ffff88810f940c80 R14: ffff88810f940d50 R15: ffff88810bc9cac0 [
    53.982634][ C1] FS: 0000000000000000(0000) GS:ffff888235880000(0000) knlGS:0000000000000000 [ 53.982634][
    C1] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 53.982634][ C1] CR2: 00007ff5f9b86680 CR3:
    0000000108ce8004 CR4: 0000000000170ee0 [ 53.982634][ C1] Call Trace: [ 53.982634][ C1] <TASK> [
    53.982634][ C1] tcp_sacktag_walk+0xaba/0x18e0 [ 53.982634][ C1] tcp_sacktag_write_queue+0xe7b/0x3460 [
    53.982634][ C1] tcp_ack+0x2666/0x54b0 [ 53.982634][ C1] tcp_rcv_established+0x4d9/0x20f0 [ 53.982634][ C1]
    tcp_v4_do_rcv+0x551/0x810 [ 53.982634][ C1] tcp_v4_rcv+0x22ed/0x2ed0 [ 53.982634][ C1]
    ip_protocol_deliver_rcu+0x96/0xaf0 [ 53.982634][ C1] ip_local_deliver_finish+0x1e0/0x2f0 [ 53.982634][ C1]
    ip_sublist_rcv_finish+0x211/0x440 [ 53.982634][ C1] ip_list_rcv_finish.constprop.0+0x424/0x660 [
    53.982634][ C1] ip_list_rcv+0x2c8/0x410 [ 53.982634][ C1] __netif_receive_skb_list_core+0x65c/0x910 [
    53.982634][ C1] netif_receive_skb_list_internal+0x5f9/0xcb0 [ 53.982634][ C1]
    napi_complete_done+0x188/0x6e0 [ 53.982634][ C1] gro_cell_poll+0x10c/0x1d0 [ 53.982634][ C1]
    __napi_poll+0xa1/0x530 [ 53.982634][ C1] net_rx_action+0x567/0x1270 [ 53.982634][ C1]
    __do_softirq+0x28a/0x9ba [ 53.982634][ C1] run_ksoftirqd+0x32/0x60 [ 53.982634][ C1]
    smpboot_thread_fn+0x559/0x8c0 [ 53.982634][ C1] kthread+0x3b9/0x490 [ 53.982634][ C1]
    ret_from_fork+0x22/0x30 [ 53.982634][ C1] </TASK> Address the issue by skipping the GRO stage for shared
    or cloned skbs. To reduce the chance of OoO, try to unclone the skbs before giving up. v1 -> v2: - use
    avoid skb_copy and fallback to netif_receive_skb - Eric (CVE-2021-47099)

  - In the Linux kernel, the following vulnerability has been resolved: ipmi: Fix UAF when uninstall ipmi_si
    and ipmi_msghandler module Hi, When testing install and uninstall of ipmi_si.ko and ipmi_msghandler.ko,
    the system crashed. The log as follows: [ 141.087026] BUG: unable to handle kernel paging request at
    ffffffffc09b3a5a [ 141.087241] PGD 8fe4c0d067 P4D 8fe4c0d067 PUD 8fe4c0f067 PMD 103ad89067 PTE 0 [
    141.087464] Oops: 0010 [#1] SMP NOPTI [ 141.087580] CPU: 67 PID: 668 Comm: kworker/67:1 Kdump: loaded Not
    tainted 4.18.0.x86_64 #47 [ 141.088009] Workqueue: events 0xffffffffc09b3a40 [ 141.088009] RIP:
    0010:0xffffffffc09b3a5a [ 141.088009] Code: Bad RIP value. [ 141.088009] RSP: 0018:ffffb9094e2c3e88
    EFLAGS: 00010246 [ 141.088009] RAX: 0000000000000000 RBX: ffff9abfdb1f04a0 RCX: 0000000000000000 [
    141.088009] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 [ 141.088009] RBP:
    0000000000000000 R08: ffff9abfffee3cb8 R09: 00000000000002e1 [ 141.088009] R10: ffffb9094cb73d90 R11:
    00000000000f4240 R12: ffff9abfffee8700 [ 141.088009] R13: 0000000000000000 R14: ffff9abfdb1f04a0 R15:
    ffff9abfdb1f04a8 [ 141.088009] FS: 0000000000000000(0000) GS:ffff9abfffec0000(0000) knlGS:0000000000000000
    [ 141.088009] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 141.088009] CR2: ffffffffc09b3a30 CR3:
    0000008fe4c0a001 CR4: 00000000007606e0 [ 141.088009] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
    0000000000000000 [ 141.088009] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [
    141.088009] PKRU: 55555554 [ 141.088009] Call Trace: [ 141.088009] ? process_one_work+0x195/0x390 [
    141.088009] ? worker_thread+0x30/0x390 [ 141.088009] ? process_one_work+0x390/0x390 [ 141.088009] ?
    kthread+0x10d/0x130 [ 141.088009] ? kthread_flush_work_fn+0x10/0x10 [ 141.088009] ?
    ret_from_fork+0x35/0x40] BUG: unable to handle kernel paging request at ffffffffc0b28a5a [ 200.223240] PGD
    97fe00d067 P4D 97fe00d067 PUD 97fe00f067 PMD a580cbf067 PTE 0 [ 200.223464] Oops: 0010 [#1] SMP NOPTI [
    200.223579] CPU: 63 PID: 664 Comm: kworker/63:1 Kdump: loaded Not tainted 4.18.0.x86_64 #46 [ 200.224008]
    Workqueue: events 0xffffffffc0b28a40 [ 200.224008] RIP: 0010:0xffffffffc0b28a5a [ 200.224008] Code: Bad
    RIP value. [ 200.224008] RSP: 0018:ffffbf3c8e2a3e88 EFLAGS: 00010246 [ 200.224008] RAX: 0000000000000000
    RBX: ffffa0799ad6bca0 RCX: 0000000000000000 [ 200.224008] RDX: 0000000000000000 RSI: 0000000000000246 RDI:
    0000000000000246 [ 200.224008] RBP: 0000000000000000 R08: ffff9fe43fde3cb8 R09: 00000000000000d5 [
    200.224008] R10: ffffbf3c8cb53d90 R11: 00000000000f4240 R12: ffff9fe43fde8700 [ 200.224008] R13:
    0000000000000000 R14: ffffa0799ad6bca0 R15: ffffa0799ad6bca8 [ 200.224008] FS: 0000000000000000(0000)
    GS:ffff9fe43fdc0000(0000) knlGS:0000000000000000 [ 200.224008] CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 [ 200.224008] CR2: ffffffffc0b28a30 CR3: 00000097fe00a002 CR4: 00000000007606e0 [
    200.224008] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 200.224008] DR3:
    0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 200.224008] PKRU: 55555554 [ 200.224008]
    Call Trace: [ 200.224008] ? process_one_work+0x195/0x390 [ 200.224008] ? worker_thread+0x30/0x390 [
    200.224008] ? process_one_work+0x390/0x390 [ 200.224008] ? kthread+0x10d/0x130 [ 200.224008] ?
    kthread_flush_work_fn+0x10/0x10 [ 200.224008] ? ret_from_fork+0x35/0x40 [ 200.224008] kernel fault(0x1)
    notification starting on CPU 63 [ 200.224008] kernel fault(0x1) notification finished on CPU 63 [
    200.224008] CR2: ffffffffc0b28a5a [ 200.224008] ---[ end trace c82a412d93f57412 ]--- The reason is as
    follows: T1: rmmod ipmi_si. ->ipmi_unregister_smi() -> ipmi_bmc_unregister() -> __ipmi_bmc_unregister() ->
    kref_put(&bmc->usecount, cleanup_bmc_device); -> schedule_work(&bmc->remove_work); T2: rmmod ipmi_msghandl
    ---truncated--- (CVE-2021-47100)

  - In the Linux kernel, the following vulnerability has been resolved: asix: fix uninit-value in
    asix_mdio_read() asix_read_cmd() may read less than sizeof(smsr) bytes and in this case smsr will be
    uninitialized. Fail log: BUG: KMSAN: uninit-value in asix_check_host_enable
    drivers/net/usb/asix_common.c:82 [inline] BUG: KMSAN: uninit-value in asix_check_host_enable
    drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 BUG: KMSAN: uninit-value in
    asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497
    asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] asix_check_host_enable
    drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 asix_mdio_read+0x3c1/0xb00
    drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497 (CVE-2021-47101)

  - In the Linux kernel, the following vulnerability has been resolved: net: marvell: prestera: fix incorrect
    structure access In line: upper = info->upper_dev; We access upper_dev field, which is related only for
    particular events (e.g. event == NETDEV_CHANGEUPPER). So, this line cause invalid memory access for
    another events, when ptr is not netdev_notifier_changeupper_info. The KASAN logs are as follows: [
    30.123165] BUG: KASAN: stack-out-of-bounds in prestera_netdev_port_event.constprop.0+0x68/0x538 [prestera]
    [ 30.133336] Read of size 8 at addr ffff80000cf772b0 by task udevd/778 [ 30.139866] [ 30.141398] CPU: 0
    PID: 778 Comm: udevd Not tainted 5.16.0-rc3 #6 [ 30.147588] Hardware name: DNI AmazonGo1 A7040 board (DT)
    [ 30.153056] Call trace: [ 30.155547] dump_backtrace+0x0/0x2c0 [ 30.159320] show_stack+0x18/0x30 [
    30.162729] dump_stack_lvl+0x68/0x84 [ 30.166491] print_address_description.constprop.0+0x74/0x2b8 [
    30.172346] kasan_report+0x1e8/0x250 [ 30.176102] __asan_load8+0x98/0xe0 [ 30.179682]
    prestera_netdev_port_event.constprop.0+0x68/0x538 [prestera] [ 30.186847]
    prestera_netdev_event_handler+0x1b4/0x1c0 [prestera] [ 30.193313] raw_notifier_call_chain+0x74/0xa0 [
    30.197860] call_netdevice_notifiers_info+0x68/0xc0 [ 30.202924] register_netdevice+0x3cc/0x760 [
    30.207190] register_netdev+0x24/0x50 [ 30.211015] prestera_device_register+0x8a0/0xba0 [prestera]
    (CVE-2021-47102)

  - In the Linux kernel, the following vulnerability has been resolved: IB/qib: Fix memory leak in
    qib_user_sdma_queue_pkts() The wrong goto label was used for the error case and missed cleanup of the pkt
    allocation. Addresses-Coverity-ID: 1493352 (Resource leak) (CVE-2021-47104)

  - In the Linux kernel, the following vulnerability has been resolved: ice: xsk: return xsk buffers back to
    pool when cleaning the ring Currently we only NULL the xdp_buff pointer in the internal SW ring but we
    never give it back to the xsk buffer pool. This means that buffers can be leaked out of the buff pool and
    never be used again. Add missing xsk_buff_free() call to the routine that is supposed to clean the entries
    that are left in the ring so that these buffers in the umem can be used by other sockets. Also, only go
    through the space that is actually left to be cleaned instead of a whole ring. (CVE-2021-47105)

  - In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix READDIR buffer overflow If a
    client sends a READDIR count argument that is too small (say, zero), then the buffer size calculation in
    the new init_dirlist helper functions results in an underflow, allowing the XDR stream functions to write
    beyond the actual buffer. This calculation has always been suspect. NFSD has never sanity- checked the
    READDIR count argument, but the old entry encoders managed the problem correctly. With the commits below,
    entry encoding changed, exposing the underflow to the pointer arithmetic in xdr_reserve_space(). Modern
    NFS clients attempt to retrieve as much data as possible for each READDIR request. Also, we have no unit
    tests that exercise the behavior of READDIR at the lower bound of @count values. Thus this case was missed
    during testing. (CVE-2021-47107)

  - In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: hdmi: Perform NULL
    pointer check for mtk_hdmi_conf In commit 41ca9caaae0b (drm/mediatek: hdmi: Add check for CEA modes
    only) a check for CEA modes was added to function mtk_hdmi_bridge_mode_valid() in order to address
    possible issues on MT8167; moreover, with commit c91026a938c2 (drm/mediatek: hdmi: Add optional limit on
    maximal HDMI mode clock) another similar check was introduced. Unfortunately though, at the time of
    writing, MT8173 does not provide any mtk_hdmi_conf structure and this is crashing the kernel with NULL
    pointer upon entering mtk_hdmi_bridge_mode_valid(), which happens as soon as a HDMI cable gets plugged in.
    To fix this regression, add a NULL pointer check for hdmi->conf in the said function, restoring HDMI
    functionality and avoiding NULL pointer kernel panics. (CVE-2021-47108)

  - In the Linux kernel, the following vulnerability has been resolved: usb: musb: tusb6010: check return
    value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource()
    returns NULL, we need check the return value. (CVE-2021-47181)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix scsi_mode_sense()
    buffer length handling Several problems exist with scsi_mode_sense() buffer length handling: 1) The
    allocation length field of the MODE SENSE(10) command is 16-bits, occupying bytes 7 and 8 of the CDB. With
    this command, access to mode pages larger than 255 bytes is thus possible. However, the CDB allocation
    length field is set by assigning len to byte 8 only, thus truncating buffer length larger than 255. 2) If
    scsi_mode_sense() is called with len smaller than 8 with sdev->use_10_for_ms set, or smaller than 4
    otherwise, the buffer length is increased to 8 and 4 respectively, and the buffer is zero filled with
    these increased values, thus corrupting the memory following the buffer. Fix these 2 problems by using
    put_unaligned_be16() to set the allocation length field of MODE SENSE(10) CDB and by returning an error
    when len is too small. Furthermore, if len is larger than 255B, always try MODE SENSE(10) first, even if
    the device driver did not set sdev->use_10_for_ms. In case of invalid opcode error for MODE SENSE(10),
    access to mode pages larger than 255 bytes are not retried using MODE SENSE(6). To avoid buffer length
    overflows for the MODE_SENSE(10) case, check that len is smaller than 65535 bytes. While at it, also fix
    the folowing: * Use get_unaligned_be16() to retrieve the mode data length and block descriptor length
    fields of the mode sense reply header instead of using an open coded calculation. * Fix the kdoc dbd
    argument explanation: the DBD bit stands for Disable Block Descriptor, which is the opposite of what the
    dbd argument description was. (CVE-2021-47182)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix link down processing
    to address NULL pointer dereference If an FC link down transition while PLOGIs are outstanding to fabric
    well known addresses, outstanding ABTS requests may result in a NULL pointer dereference. Driver unload
    requests may hang with repeated 2878 log messages. The Link down processing results in ABTS requests for
    outstanding ELS requests. The Abort WQEs are sent for the ELSs before the driver had set the link state to
    down. Thus the driver is sending the Abort with the expectation that an ABTS will be sent on the wire. The
    Abort request is stalled waiting for the link to come up. In some conditions the driver may auto-complete
    the ELSs thus if the link does come up, the Abort completions may reference an invalid structure. Fix by
    ensuring that Abort set the flag to avoid link traffic if issued due to conditions where the link failed.
    (CVE-2021-47183)

  - In the Linux kernel, the following vulnerability has been resolved: tty: tty_buffer: Fix the softlockup
    issue in flush_to_ldisc When running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a
    soft lockup, which look like this one: Workqueue: events_unbound flush_to_ldisc Call trace:
    dump_backtrace+0x0/0x1ec show_stack+0x24/0x30 dump_stack+0xd0/0x128 panic+0x15c/0x374
    watchdog_timer_fn+0x2b8/0x304 __run_hrtimer+0x88/0x2c0 __hrtimer_run_queues+0xa4/0x120
    hrtimer_interrupt+0xfc/0x270 arch_timer_handler_phys+0x40/0x50 handle_percpu_devid_irq+0x94/0x220
    __handle_domain_irq+0x88/0xf0 gic_handle_irq+0x84/0xfc el1_irq+0xc8/0x180 slip_unesc+0x80/0x214 [slip]
    tty_ldisc_receive_buf+0x64/0x80 tty_port_default_receive_buf+0x50/0x90 flush_to_ldisc+0xbc/0x110
    process_one_work+0x1d4/0x4b0 worker_thread+0x180/0x430 kthread+0x11c/0x120 In the testcase pty04, The
    first process call the write syscall to send data to the pty master. At the same time, the workqueue will
    do the flush_to_ldisc to pop data in a loop until there is no more data left. When the sender and
    workqueue running in different core, the sender sends data fastly in full time which will result in
    workqueue doing work in loop for a long time and occuring softlockup in flush_to_ldisc with kernel
    configured without preempt. So I add need_resched check and cond_resched in the flush_to_ldisc loop to
    avoid it. (CVE-2021-47185)

  - In the Linux kernel, the following vulnerability has been resolved: btrfs: fix memory ordering between
    normal and ordered work functions Ordered work functions aren't guaranteed to be handled by the same
    thread which executed the normal work functions. The only way execution between normal/ordered functions
    is synchronized is via the WORK_DONE_BIT, unfortunately the used bitops don't guarantee any ordering
    whatsoever. This manifested as seemingly inexplicable crashes on ARM64, where async_chunk::inode is seen
    as non-null in async_cow_submit which causes submit_compressed_extents to be called and crash occurs
    because async_chunk::inode suddenly became NULL. The call trace was similar to: pc :
    submit_compressed_extents+0x38/0x3d0 lr : async_cow_submit+0x50/0xd0 sp : ffff800015d4bc20 <registers
    omitted for brevity> Call trace: submit_compressed_extents+0x38/0x3d0 async_cow_submit+0x50/0xd0
    run_ordered_work+0xc8/0x280 btrfs_work_helper+0x98/0x250 process_one_work+0x1f0/0x4ac
    worker_thread+0x188/0x504 kthread+0x110/0x114 ret_from_fork+0x10/0x18 Fix this by adding respective
    barrier calls which ensure that all accesses preceding setting of WORK_DONE_BIT are strictly ordered
    before setting the flag. At the same time add a read barrier after reading of WORK_DONE_BIT in
    run_ordered_work which ensures all subsequent loads would be strictly ordered after reading the bit. This
    in turn ensures are all accesses before WORK_DONE_BIT are going to be strictly ordered before any access
    that can occur in ordered_func. (CVE-2021-47189)

  - A double-free flaw was found in the Linux kernel's TUN/TAP device driver functionality in how a user
    registers the device when the register_netdevice function fails (NETDEV_REGISTER notifier). This flaw
    allows a local user to crash or potentially escalate their privileges on the system. (CVE-2022-4744)

  - In the Linux kernel, the following vulnerability has been resolved: moxart: fix potential use-after-free
    on remove path It was reported that the mmc host structure could be accessed after it was freed in
    moxart_remove(), so fix this by saving the base register of the device and using it instead of the pointer
    dereference. (CVE-2022-48626)

  - In the Linux kernel, the following vulnerability has been resolved: crypto: qcom-rng - ensure buffer for
    generate is completely filled The generate function in struct rng_alg expects that the destination buffer
    is completely filled if the function returns 0. qcom_rng_read() can run into a situation where the buffer
    is partially filled with randomness and the remaining part of the buffer is zeroed since
    qcom_rng_generate() doesn't check the return value. This issue can be reproduced by running the following
    from libkcapi: kcapi-rng -b 9000000 > OUTFILE The generated OUTFILE will have three huge sections that
    contain all zeros, and this is caused by the code where the test 'val & PRNG_STATUS_DATA_AVAIL' fails.
    Let's fix this issue by ensuring that qcom_rng_read() always returns with a full buffer if the function
    returns success. Let's also have qcom_rng_generate() return the correct value. Here's some statistics from
    the ent project (https://www.fourmilab.ch/random/) that shows information about the quality of the
    generated numbers: $ ent -c qcom-random-before Value Char Occurrences Fraction 0 606748 0.067416 1 33104
    0.003678 2 33001 0.003667 ... 253  32883 0.003654 254  33035 0.003671 255  33239 0.003693 Total:
    9000000 1.000000 Entropy = 7.811590 bits per byte. Optimum compression would reduce the size of this
    9000000 byte file by 2 percent. Chi square distribution for 9000000 samples is 9329962.81, and randomly
    would exceed this value less than 0.01 percent of the times. Arithmetic mean value of data bytes is
    119.3731 (127.5 = random). Monte Carlo value for Pi is 3.197293333 (error 1.77 percent). Serial
    correlation coefficient is 0.159130 (totally uncorrelated = 0.0). Without this patch, the results of the
    chi-square test is 0.01%, and the numbers are certainly not random according to ent's project page. The
    results improve with this patch: $ ent -c qcom-random-after Value Char Occurrences Fraction 0 35432
    0.003937 1 35127 0.003903 2 35424 0.003936 ... 253  35201 0.003911 254  34835 0.003871 255  35368
    0.003930 Total: 9000000 1.000000 Entropy = 7.999979 bits per byte. Optimum compression would reduce the
    size of this 9000000 byte file by 0 percent. Chi square distribution for 9000000 samples is 258.77, and
    randomly would exceed this value 42.24 percent of the times. Arithmetic mean value of data bytes is
    127.5006 (127.5 = random). Monte Carlo value for Pi is 3.141277333 (error 0.01 percent). Serial
    correlation coefficient is 0.000468 (totally uncorrelated = 0.0). This change was tested on a Nexus 5
    phone (msm8974 SoC). (CVE-2022-48629)

  - In the Linux kernel, the following vulnerability has been resolved: crypto: qcom-rng - fix infinite loop
    on requests not multiple of WORD_SZ The commit referenced in the Fixes tag removed the 'break' from the
    else branch in qcom_rng_read(), causing an infinite loop whenever 'max' is not a multiple of WORD_SZ. This
    can be reproduced e.g. by running: kcapi-rng -b 67 >/dev/null There are many ways to fix this without
    adding back the 'break', but they all seem more awkward than simply adding it back, so do just that.
    Tested on a machine with Qualcomm Amberwing processor. (CVE-2022-48630)

  - A deadlock flaw was found in the Linux kernel's BPF subsystem. This flaw allows a local user to
    potentially crash the system. (CVE-2023-0160)

  - Information exposure through microarchitectural state after transient execution from some register files
    for some Intel(R) Atom(R) Processors may allow an authenticated user to potentially enable information
    disclosure via local access. (CVE-2023-28746)

  - An issue was discovered in the Linux kernel through 6.3.8. A use-after-free was found in ravb_remove in
    drivers/net/ethernet/renesas/ravb_main.c. (CVE-2023-35827)

  - Rejected reason: CVE-2023-4881 was wrongly assigned to a bug that was deemed to be a non-security issue by
    the Linux kernel security team. (CVE-2023-4881)

  - 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: perf/x86/intel/uncore: Fix NULL
    pointer dereference issue in upi_fill_topology() Get logical socket id instead of physical id in
    discover_upi_topology() to avoid out-of-bound access on 'upi = &type->topology[nid][idx];' line that leads
    to NULL pointer dereference in upi_fill_topology() (CVE-2023-52450)

  - In the Linux kernel, the following vulnerability has been resolved: hisi_acc_vfio_pci: Update migration
    data pointer correctly on saving/resume When the optional PRE_COPY support was added to speed up the
    device compatibility check, it failed to update the saving/resuming data pointers based on the fd offset.
    This results in migration data corruption and when the device gets started on the destination the
    following error is reported in some cases, [ 478.907684] arm-smmu-v3 arm-smmu-v3.2.auto: event 0x10
    received: [ 478.913691] arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000310200000010 [ 478.919603] arm-smmu-v3 arm-
    smmu-v3.2.auto: 0x000002088000007f [ 478.925515] arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000000000000000 [
    478.931425] arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000000000000000 [ 478.947552] hisi_zip 0000:31:00.0:
    qm_axi_rresp [error status=0x1] found [ 478.955930] hisi_zip 0000:31:00.0: qm_db_timeout [error
    status=0x400] found [ 478.955944] hisi_zip 0000:31:00.0: qm sq doorbell timeout in function 2
    (CVE-2023-52453)

  - 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: 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: IB/hfi1: Fix bugs with non-PAGE_SIZE-
    end multi-iovec user SDMA requests hfi1 user SDMA request processing has two bugs that can cause data
    corruption for user SDMA requests that have multiple payload iovecs where an iovec other than the tail
    iovec does not run up to the page boundary for the buffer pointed to by that iovec.a Here are the specific
    bugs: 1. user_sdma_txadd() does not use struct user_sdma_iovec->iov.iov_len. Rather, user_sdma_txadd()
    will add up to PAGE_SIZE bytes from iovec to the packet, even if some of those bytes are past
    iovec->iov.iov_len and are thus not intended to be in the packet. 2. user_sdma_txadd() and
    user_sdma_send_pkts() fail to advance to the next iovec in user_sdma_request->iovs when the current iovec
    is not PAGE_SIZE and does not contain enough data to complete the packet. The transmitted packet will
    contain the wrong data from the iovec pages. This has not been an issue with SDMA packets from hfi1 Verbs
    or PSM2 because they only produce iovecs that end short of PAGE_SIZE as the tail iovec of an SDMA request.
    Fixing these bugs exposes other bugs with the SDMA pin cache (struct mmu_rb_handler) that get in way of
    supporting user SDMA requests with multiple payload iovecs whose buffers do not end at PAGE_SIZE. So this
    commit fixes those issues as well. Here are the mmu_rb_handler bugs that non-PAGE_SIZE-end multi-iovec
    payload user SDMA requests can hit: 1. Overlapping memory ranges in mmu_rb_handler will result in
    duplicate pinnings. 2. When extending an existing mmu_rb_handler entry (struct mmu_rb_node), the mmu_rb
    code (1) removes the existing entry under a lock, (2) releases that lock, pins the new pages, (3) then
    reacquires the lock to insert the extended mmu_rb_node. If someone else comes in and inserts an
    overlapping entry between (2) and (3), insert in (3) will fail. The failure path code in this case unpins
    _all_ pages in either the original mmu_rb_node or the new mmu_rb_node that was inserted between (2) and
    (3). 3. In hfi1_mmu_rb_remove_unless_exact(), mmu_rb_node->refcount is incremented outside of
    mmu_rb_handler->lock. As a result, mmu_rb_node could be evicted by another thread that gets
    mmu_rb_handler->lock and checks mmu_rb_node->refcount before mmu_rb_node->refcount is incremented. 4.
    Related to #2 above, SDMA request submission failure path does not check mmu_rb_node->refcount before
    freeing mmu_rb_node object. If there are other SDMA requests in progress whose iovecs have pointers to the
    now-freed mmu_rb_node(s), those pointers to the now-freed mmu_rb nodes will be dereferenced when those
    SDMA requests complete. (CVE-2023-52474)

  - In the Linux kernel, the following vulnerability has been resolved: perf/x86/lbr: Filter vsyscall
    addresses We found that a panic can occur when a vsyscall is made while LBR sampling is active. If the
    vsyscall is interrupted (NMI) for perf sampling, this call sequence can occur (most recent at top):
    __insn_get_emulate_prefix() insn_get_emulate_prefix() insn_get_prefixes() insn_get_opcode()
    decode_branch_type() get_branch_type() intel_pmu_lbr_filter() intel_pmu_handle_irq()
    perf_event_nmi_handler() Within __insn_get_emulate_prefix() at frame 0, a macro is called:
    peek_nbyte_next(insn_byte_t, insn, i) Within this macro, this dereference occurs: (insn)->next_byte
    Inspecting registers at this point, the value of the next_byte field is the address of the vsyscall made,
    for example the location of the vsyscall version of gettimeofday() at 0xffffffffff600000. The access to an
    address in the vsyscall region will trigger an oops due to an unhandled page fault. To fix the bug,
    filtering for vsyscalls can be done when determining the branch type. This patch will return a none
    branch if a kernel address if found to lie in the vsyscall region. (CVE-2023-52476)

  - In the Linux kernel, the following vulnerability has been resolved: usb: hub: Guard against accesses to
    uninitialized BOS descriptors Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access
    fields inside udev->bos without checking if it was allocated and initialized. If usb_get_bos_descriptor()
    fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash: BUG: kernel
    NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 5
    PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1> Hardware name:
    Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021 Workqueue: usb_hub_wq hub_event RIP:
    0010:hub_port_reset+0x193/0x788 Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88
    92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02
    00 00 00 4c 89 e9 RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa1bc5f678000
    RCX: 0000000000000310 RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840 RBP:
    ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060 R10: 0000000000000001 R11: 0000000000000000
    R12: 0000000000000000 R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000 FS:
    0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0 Call Trace:
    hub_event+0x73f/0x156e ? hub_activate+0x5b7/0x68f process_one_work+0x1a2/0x487 worker_thread+0x11a/0x288
    kthread+0x13a/0x152 ? process_one_work+0x487/0x487 ? kthread_associate_blkcg+0x70/0x70
    ret_from_fork+0x1f/0x30 Fall back to a default behavior if the BOS descriptor isn't accessible and skip
    all the functionalities that depend on it: LPM support checks, Super Speed capabilitiy checks, U1/U2
    states setup. (CVE-2023-52477)

  - In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Add Cortex-A520
    speculative unprivileged load workaround Implement the workaround for ARM Cortex-A520 erratum 2966298. On
    an affected Cortex-A520 core, a speculatively executed unprivileged load might leak data from a privileged
    load via a cache side channel. The issue only exists for loads within a translation regime with the same
    translation (e.g. same ASID and VMID). Therefore, the issue only affects the return to EL0. The workaround
    is to execute a TLBI before returning to EL0 after all loads of privileged data. A non-shareable TLBI to
    any address is sufficient. The workaround isn't necessary if page table isolation (KPTI) is enabled, but
    for simplicity it will be. Page table isolation should normally be disabled for Cortex-A520 as it supports
    the CSV3 feature and the E0PD feature (used when KASLR is enabled). (CVE-2023-52481)

  - In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu-v3: Fix soft lockup
    triggered by arm_smmu_mm_invalidate_range When running an SVA case, the following soft lockup is
    triggered: -------------------------------------------------------------------- watchdog: BUG: soft lockup
    - CPU#244 stuck for 26s! pstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc :
    arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 lr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50 sp : ffff8000d83ef290
    x29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000 x26: ffff8000d83ef3c0 x25:
    da86c0812194a0e8 x24: 0000000000000000 x23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0
    x20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000 x17: 0000000000000000 x16:
    0000000000000000 x15: ffff3000b4a3bbb0 x14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000
    x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bc x8 : 0000000000000000 x7 :
    0000000000000000 x6 : 0000000000048cfa x5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000a
    x2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace:
    arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 __arm_smmu_tlb_inv_range+0x118/0x254
    arm_smmu_tlb_inv_range_asid+0x6c/0x130 arm_smmu_mm_invalidate_range+0xa0/0xa4
    __mmu_notifier_invalidate_range_end+0x88/0x120 unmap_vmas+0x194/0x1e0 unmap_region+0xb4/0x144
    do_mas_align_munmap+0x290/0x490 do_mas_munmap+0xbc/0x124 __vm_munmap+0xa8/0x19c
    __arm64_sys_munmap+0x28/0x50 invoke_syscall+0x78/0x11c el0_svc_common.constprop.0+0x58/0x1c0
    do_el0_svc+0x34/0x60 el0_svc+0x2c/0xd4 el0t_64_sync_handler+0x114/0x140 el0t_64_sync+0x1a4/0x1a8
    -------------------------------------------------------------------- Note that since 6.6-rc1 the
    arm_smmu_mm_invalidate_range above is renamed to arm_smmu_mm_arch_invalidate_secondary_tlbs, yet the
    problem remains. The commit 06ff87bae8d3 (arm64: mm: remove unused functions and variable protoypes)
    fixed a similar lockup on the CPU MMU side. Yet, it can occur to SMMU too, since
    arm_smmu_mm_arch_invalidate_secondary_tlbs() is called typically next to MMU tlb flush function, e.g.
    tlb_flush_mmu_tlbonly { tlb_flush { __flush_tlb_range { // check MAX_TLBI_OPS } }
    mmu_notifier_arch_invalidate_secondary_tlbs { arm_smmu_mm_arch_invalidate_secondary_tlbs { // does not
    check MAX_TLBI_OPS } } } Clone a CMDQ_MAX_TLBI_OPS from the MAX_TLBI_OPS in tlbflush.h, since in an SVA
    case SMMU uses the CPU page table, so it makes sense to align with the tlbflush code. Then, replace per-
    page TLBI commands with a single per-asid TLBI command, if the request size hits this threshold.
    (CVE-2023-52484)

  - In the Linux kernel, the following vulnerability has been resolved: drm: Don't unref the same fb many
    times by mistake due to deadlock handling If we get a deadlock after the fb lookup in
    drm_mode_page_flip_ioctl() we proceed to unref the fb and then retry the whole thing from the top. But we
    forget to reset the fb pointer back to NULL, and so if we then get another error during the retry, before
    the fb lookup, we proceed the unref the same fb again without having gotten another reference. The end
    result is that the fb will (eventually) end up being freed while it's still in use. Reset fb to NULL once
    we've unreffed it to avoid doing it again until we've done another fb lookup. This turned out to be pretty
    easy to hit on a DG2 when doing async flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I
    saw that drm_closefb() simply got stuck in a busy loop while walking the framebuffer list. Fortunately I
    was able to convince it to oops instead, and from there it was easier to track down the culprit.
    (CVE-2023-52486)

  - In the Linux kernel, the following vulnerability has been resolved: serial: sc16is7xx: convert from _raw_
    to _noinc_ regmap functions for FIFO The SC16IS7XX IC supports a burst mode to access the FIFOs where the
    initial register address is sent ($00), followed by all the FIFO data without having to resend the
    register address each time. In this mode, the IC doesn't increment the register address for each R/W byte.
    The regmap_raw_read() and regmap_raw_write() are functions which can perform IO over multiple registers.
    They are currently used to read/write from/to the FIFO, and although they operate correctly in this burst
    mode on the SPI bus, they would corrupt the regmap cache if it was not disabled manually. The reason is
    that when the R/W size is more than 1 byte, these functions assume that the register address is
    incremented and handle the cache accordingly. Convert FIFO R/W functions to use the regmap _noinc_
    versions in order to remove the manual cache control which was a workaround when using the _raw_ versions.
    FIFO registers are properly declared as volatile so cache will not be used/updated for FIFO accesses.
    (CVE-2023-52488)

  - In the Linux kernel, the following vulnerability has been resolved: dmaengine: fix NULL pointer in channel
    unregistration function __dma_async_device_channel_register() can fail. In case of failure, chan->local is
    freed (with free_percpu()), and chan->local is nullified. When dma_async_device_unregister() is called
    (because of managed API or intentionally by DMA controller driver), channels are unconditionally
    unregistered, leading to this NULL pointer: [ 1.318693] Unable to handle kernel NULL pointer dereference
    at virtual address 00000000000000d0 [...] [ 1.484499] Call trace: [ 1.486930] device_del+0x40/0x394 [
    1.490314] device_unregister+0x20/0x7c [ 1.494220] __dma_async_device_channel_unregister+0x68/0xc0 Look at
    dma_async_device_register() function error path, channel device unregistration is done only if chan->local
    is not NULL. Then add the same condition at the beginning of __dma_async_device_channel_unregister()
    function, to avoid NULL pointer issue whatever the API used to reach this function. (CVE-2023-52492)

  - In the Linux kernel, the following vulnerability has been resolved: bus: mhi: host: Drop chan lock before
    queuing buffers Ensure read and write locks for the channel are not taken in succession by dropping the
    read lock from parse_xfer_event() such that a callback given to client can potentially queue buffers and
    acquire the write lock in that process. Any queueing of buffers should be done without channel read lock
    acquired as it can result in multiple locks and a soft lockup. [mani: added fixes tag and cc'ed stable]
    (CVE-2023-52493)

  - In the Linux kernel, the following vulnerability has been resolved: bus: mhi: host: Add alignment check
    for event ring read pointer Though we do check the event ring read pointer by is_valid_ring_ptr to make
    sure it is in the buffer range, but there is another risk the pointer may be not aligned. Since we are
    expecting event ring elements are 128 bits(struct mhi_ring_element) aligned, an unaligned read pointer
    could lead to multiple issues like DoS or ring buffer memory corruption. So add a alignment check for
    event ring read pointer. (CVE-2023-52494)

  - In the Linux kernel, the following vulnerability has been resolved: erofs: fix lz4 inplace decompression
    Currently EROFS can map another compressed buffer for inplace decompression, that was used to handle the
    cases that some pages of compressed data are actually not in-place I/O. However, like most simple LZ77
    algorithms, LZ4 expects the compressed data is arranged at the end of the decompressed buffer and it
    explicitly uses memmove() to handle overlapping:
    __________________________________________________________ |_ direction of decompression --> ____ |_
    compressed data _| Although EROFS arranges compressed data like this, it typically maps two individual
    virtual buffers so the relative order is uncertain. Previously, it was hardly observed since LZ4 only uses
    memmove() for short overlapped literals and x86/arm64 memmove implementations seem to completely cover it
    up and they don't have this issue. Juhyung reported that EROFS data corruption can be found on a new Intel
    x86 processor. After some analysis, it seems that recent x86 processors with the new FSRM feature expose
    this issue with rep movsb. Let's strictly use the decompressed buffer for lz4 inplace decompression for
    now. Later, as an useful improvement, we could try to tie up these two buffers together in the correct
    order. (CVE-2023-52497)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: pm80xx: Avoid leaking tags when
    processing OPC_INB_SET_CONTROLLER_CONFIG command Tags allocated for OPC_INB_SET_CONTROLLER_CONFIG command
    need to be freed when we receive the response. (CVE-2023-52500)

  - In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Do not attempt to read
    past commit When iterating over the ring buffer while the ring buffer is active, the writer can corrupt
    the reader. There's barriers to help detect this and handle it, but that code missed the case where the
    last event was at the very end of the page and has only 4 bytes left. The checks to detect the corruption
    by the writer to reads needs to see the length of the event. If the length in the first 4 bytes is zero
    then the length is stored in the second 4 bytes. But if the writer is in the process of updating that
    code, there's a small window where the length in the first 4 bytes could be zero even though the length is
    only 4 bytes. That will cause rb_event_length() to read the next 4 bytes which could happen to be off the
    allocated page. To protect against this, fail immediately if the next event pointer is less than 8 bytes
    from the end of the commit (last byte of data), as all events must be a minimum of 8 bytes anyway.
    (CVE-2023-52501)

  - In the Linux kernel, the following vulnerability has been resolved: net: nfc: fix races in
    nfc_llcp_sock_get() and nfc_llcp_sock_get_sn() Sili Luo reported a race in nfc_llcp_sock_get(), leading to
    UAF. Getting a reference on the socket found in a lookup while holding a lock should happen before
    releasing the lock. nfc_llcp_sock_get_sn() has a similar problem. Finally nfc_llcp_recv_snl() needs to
    make sure the socket found by nfc_llcp_sock_from_sn() does not disappear. (CVE-2023-52502)

  - In the Linux kernel, the following vulnerability has been resolved: tee: amdtee: fix use-after-free
    vulnerability in amdtee_close_session There is a potential race condition in amdtee_close_session that may
    cause use-after-free in amdtee_open_session. For instance, if a session has refcount == 1, and one thread
    tries to free this session via: kref_put(&sess->refcount, destroy_session); the reference count will get
    decremented, and the next step would be to call destroy_session(). However, if in another thread,
    amdtee_open_session() is called before destroy_session() has completed execution, alloc_session() may
    return 'sess' that will be freed up later in destroy_session() leading to use-after-free in
    amdtee_open_session. To fix this issue, treat decrement of sess->refcount and removal of 'sess' from
    session list in destroy_session() as a critical section, so that it is executed atomically.
    (CVE-2023-52503)

  - In the Linux kernel, the following vulnerability has been resolved: x86/alternatives: Disable KASAN in
    apply_alternatives() Fei has reported that KASAN triggers during apply_alternatives() on a 5-level paging
    machine: BUG: KASAN: out-of-bounds in rcu_is_watching() Read of size 4 at addr ff110003ee6419a0 by task
    swapper/0/0 ... __asan_load4() rcu_is_watching() trace_hardirqs_on() text_poke_early()
    apply_alternatives() ... On machines with 5-level paging, cpu_feature_enabled(X86_FEATURE_LA57) gets
    patched. It includes KASAN code, where KASAN_SHADOW_START depends on __VIRTUAL_MASK_SHIFT, which is
    defined with cpu_feature_enabled(). KASAN gets confused when apply_alternatives() patches the
    KASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_START static, by replacing
    __VIRTUAL_MASK_SHIFT with 56, works around the issue. Fix it for real by disabling KASAN while the kernel
    is patching alternatives. [ mingo: updated the changelog ] (CVE-2023-52504)

  - In the Linux kernel, the following vulnerability has been resolved: nfc: nci: assert requested protocol is
    valid The protocol is used in a bit mask to determine if the protocol is supported. Assert the provided
    protocol is less than the maximum defined so it doesn't potentially perform a shift-out-of-bounds and
    provide a clearer error for undefined protocols vs unsupported ones. (CVE-2023-52507)

  - In the Linux kernel, the following vulnerability has been resolved: nvme-fc: Prevent null pointer
    dereference in nvme_fc_io_getuuid() The nvme_fc_fcp_op structure describing an AEN operation is
    initialized with a null request structure pointer. An FC LLDD may make a call to nvme_fc_io_getuuid
    passing a pointer to an nvmefc_fcp_req for an AEN operation. Add validation of the request structure
    pointer before dereference. (CVE-2023-52508)

  - In the Linux kernel, the following vulnerability has been resolved: ravb: Fix use-after-free issue in
    ravb_tx_timeout_work() The ravb_stop() should call cancel_work_sync(). Otherwise, ravb_tx_timeout_work()
    is possible to use the freed priv after ravb_remove() was called like below: CPU0 CPU1 ravb_tx_timeout()
    ravb_remove() unregister_netdev() free_netdev(ndev) // free priv ravb_tx_timeout_work() // use priv
    unregister_netdev() will call .ndo_stop() so that ravb_stop() is called. And, after phy_stop() is called,
    netif_carrier_off() is also called. So that .ndo_tx_timeout() will not be called after phy_stop().
    (CVE-2023-52509)

  - In the Linux kernel, the following vulnerability has been resolved: ieee802154: ca8210: Fix a potential
    UAF in ca8210_probe If of_clk_add_provider() fails in ca8210_register_ext_clock(), it calls
    clk_unregister() to release priv->clk and returns an error. However, the caller ca8210_probe() then calls
    ca8210_remove(), where priv->clk is freed again in ca8210_unregister_ext_clock(). In this case, a use-
    after-free may happen in the second time we call clk_unregister(). Fix this by removing the first
    clk_unregister(). Also, priv->clk could be an error code on failure of clk_register_fixed_rate(). Use
    IS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock(). (CVE-2023-52510)

  - In the Linux kernel, the following vulnerability has been resolved: spi: sun6i: reduce DMA RX transfer
    width to single byte Through empirical testing it has been determined that sometimes RX SPI transfers with
    DMA enabled return corrupted data. This is down to single or even multiple bytes lost during DMA transfer
    from SPI peripheral to memory. It seems the RX FIFO within the SPI peripheral can become confused when
    performing bus read accesses wider than a single byte to it during an active SPI transfer. This patch
    reduces the width of individual DMA read accesses to the RX FIFO to a single byte to mitigate that issue.
    (CVE-2023-52511)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix connection failure
    handling In case immediate MPA request processing fails, the newly created endpoint unlinks the listening
    endpoint and is ready to be dropped. This special case was not handled correctly by the code handling the
    later TCP socket close, causing a NULL dereference crash in siw_cm_work_handler() when dereferencing a
    NULL listener. We now also cancel the useless MPA timeout, if immediate MPA request processing fails. This
    patch furthermore simplifies MPA processing in general: Scheduling a useless TCP socket read in
    sk_data_ready() upcall is now surpressed, if the socket is already moved out of TCP_ESTABLISHED state.
    (CVE-2023-52513)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: Do not call scsi_done() from
    srp_abort() After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler callback, it performs
    one of the following actions: * Call scsi_queue_insert(). * Call scsi_finish_command(). * Call
    scsi_eh_scmd_add(). Hence, SCSI abort handlers must not call scsi_done(). Otherwise all the above actions
    would trigger a use-after-free. Hence remove the scsi_done() call from srp_abort(). Keep the
    srp_free_req() call before returning SUCCESS because we may not see the command again if SUCCESS is
    returned. (CVE-2023-52515)

  - In the Linux kernel, the following vulnerability has been resolved: spi: sun6i: fix race between DMA RX
    transfer completion and RX FIFO drain Previously the transfer complete IRQ immediately drained to RX FIFO
    to read any data remaining in FIFO to the RX buffer. This behaviour is correct when dealing with SPI in
    interrupt mode. However in DMA mode the transfer complete interrupt still fires as soon as all bytes to be
    transferred have been stored in the FIFO. At that point data in the FIFO still needs to be picked up by
    the DMA engine. Thus the drain procedure and DMA engine end up racing to read from RX FIFO, corrupting any
    data read. Additionally the RX buffer pointer is never adjusted according to DMA progress in DMA mode,
    thus calling the RX FIFO drain procedure in DMA mode is a bug. Fix corruptions in DMA RX mode by draining
    RX FIFO only in interrupt mode. Also wait for completion of RX DMA when in DMA mode before returning to
    ensure all data has been copied to the supplied memory buffer. (CVE-2023-52517)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_codec: Fix leaking
    content of local_codecs The following memory leak can be observed when the controller supports codecs
    which are stored in local_codecs list but the elements are never freed: unreferenced object
    0xffff88800221d840 (size 32): comm kworker/u3:0, pid 36, jiffies 4294898739 (age 127.060s) hex dump
    (first 32 bytes): f8 d3 02 03 80 88 ff ff 80 d8 21 02 80 88 ff ff ..........!..... 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffffb324f557>] __kmalloc+0x47/0x120
    [<ffffffffb39ef37d>] hci_codec_list_add.isra.0+0x2d/0x160 [<ffffffffb39ef643>]
    hci_read_codec_capabilities+0x183/0x270 [<ffffffffb39ef9ab>] hci_read_supported_codecs+0x1bb/0x2d0
    [<ffffffffb39f162e>] hci_read_local_codecs_sync+0x3e/0x60 [<ffffffffb39ff1b3>]
    hci_dev_open_sync+0x943/0x11e0 [<ffffffffb396d55d>] hci_power_on+0x10d/0x3f0 [<ffffffffb30c99b4>]
    process_one_work+0x404/0x800 [<ffffffffb30ca134>] worker_thread+0x374/0x670 [<ffffffffb30d9108>]
    kthread+0x188/0x1c0 [<ffffffffb304db6b>] ret_from_fork+0x2b/0x50 [<ffffffffb300206a>]
    ret_from_fork_asm+0x1a/0x30 (CVE-2023-52518)

  - In the Linux kernel, the following vulnerability has been resolved: HID: intel-ish-hid: ipc: Disable and
    reenable ACPI GPE bit The EHL (Elkhart Lake) based platforms provide a OOB (Out of band) service, which
    allows to wakup device when the system is in S5 (Soft-Off state). This OOB service can be enabled/disabled
    from BIOS settings. When enabled, the ISH device gets PME wake capability. To enable PME wakeup, driver
    also needs to enable ACPI GPE bit. On resume, BIOS will clear the wakeup bit. So driver need to re-enable
    it in resume function to keep the next wakeup capability. But this BIOS clearing of wakeup bit doesn't
    decrement internal OS GPE reference count, so this reenabling on every resume will cause reference count
    to overflow. So first disable and reenable ACPI GPE bit using acpi_disable_gpe(). (CVE-2023-52519)

  - In the Linux kernel, the following vulnerability has been resolved: platform/x86: think-lmi: Fix reference
    leak If a duplicate attribute is found using kset_find_obj(), a reference to that attribute is returned
    which needs to be disposed accordingly using kobject_put(). Move the setting name validation into a
    separate function to allow for this change without having to duplicate the cleanup code for this setting.
    As a side note, a very similar bug was fixed in commit 7295a996fdab (platform/x86: dell-sysman: Fix
    reference leak), so it seems that the bug was copied from that driver. Compile-tested only.
    (CVE-2023-52520)

  - In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Reject sk_msg egress
    redirects to non-TCP sockets With a SOCKMAP/SOCKHASH map and an sk_msg program user can steer messages
    sent from one TCP socket (s1) to actually egress from another TCP socket (s2): tcp_bpf_sendmsg(s1) // =
    sk_prot->sendmsg tcp_bpf_send_verdict(s1) // __SK_REDIRECT case tcp_bpf_sendmsg_redir(s2)
    tcp_bpf_push_locked(s2) tcp_bpf_push(s2) tcp_rate_check_app_limited(s2) // expects tcp_sock
    tcp_sendmsg_locked(s2) // ditto There is a hard-coded assumption in the call-chain, that the egress socket
    (s2) is a TCP socket. However in commit 122e6c79efe1 (sock_map: Update sock type checks for UDP) we have
    enabled redirects to non-TCP sockets. This was done for the sake of BPF sk_skb programs. There was no
    indention to support sk_msg send-to-egress use case. As a result, attempts to send-to-egress through a
    non-TCP socket lead to a crash due to invalid downcast from sock to tcp_sock: BUG: kernel NULL pointer
    dereference, address: 000000000000002f ... Call Trace: <TASK> ? show_regs+0x60/0x70 ? __die+0x1f/0x70 ?
    page_fault_oops+0x80/0x160 ? do_user_addr_fault+0x2d7/0x800 ? rcu_is_watching+0x11/0x50 ?
    exc_page_fault+0x70/0x1c0 ? asm_exc_page_fault+0x27/0x30 ? tcp_tso_segs+0x14/0xa0
    tcp_write_xmit+0x67/0xce0 __tcp_push_pending_frames+0x32/0xf0 tcp_push+0x107/0x140
    tcp_sendmsg_locked+0x99f/0xbb0 tcp_bpf_push+0x19d/0x3a0 tcp_bpf_sendmsg_redir+0x55/0xd0
    tcp_bpf_send_verdict+0x407/0x550 tcp_bpf_sendmsg+0x1a1/0x390 inet_sendmsg+0x6a/0x70 sock_sendmsg+0x9d/0xc0
    ? sockfd_lookup_light+0x12/0x80 __sys_sendto+0x10e/0x160 ? syscall_enter_from_user_mode+0x20/0x60 ?
    __this_cpu_preempt_check+0x13/0x20 ? lockdep_hardirqs_on+0x82/0x110 __x64_sys_sendto+0x1f/0x30
    do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Reject selecting a non-TCP sockets as
    redirect target from a BPF sk_msg program to prevent the crash. When attempted, user will receive an
    EACCES error from send/sendto/sendmsg() syscall. (CVE-2023-52523)

  - In the Linux kernel, the following vulnerability has been resolved: net: nfc: llcp: Add lock when
    modifying device list The device list needs its associated lock held when modifying it, or the list could
    become corrupted, as syzbot discovered. (CVE-2023-52524)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix oob check condition
    in mwifiex_process_rx_packet Only skip the code path trying to access the rfc1042 headers when the buffer
    is too small, so the driver can still process packets without rfc1042 headers. (CVE-2023-52525)

  - In the Linux kernel, the following vulnerability has been resolved: net: usb: smsc75xx: Fix uninit-value
    access in __smsc75xx_read_reg syzbot reported the following uninit-value access issue:
    ===================================================== BUG: KMSAN: uninit-value in smsc75xx_wait_ready
    drivers/net/usb/smsc75xx.c:975 [inline] BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0
    drivers/net/usb/smsc75xx.c:1482 CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue:
    usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x21c/0x280
    lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121 __msan_warning+0x58/0xa0
    mm/kmsan/kmsan_instr.c:215 smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]
    smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482 usbnet_probe+0x1152/0x3f90
    drivers/net/usb/usbnet.c:1737 usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374
    really_probe+0xf20/0x20b0 drivers/base/dd.c:529 driver_probe_device+0x293/0x390 drivers/base/dd.c:701
    __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807 bus_for_each_drv+0x2ca/0x3f0
    drivers/base/bus.c:431 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873 device_initial_probe+0x4a/0x60
    drivers/base/dd.c:920 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491 device_add+0x3b0e/0x40d0
    drivers/base/core.c:2680 usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032
    usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241 usb_probe_device+0x311/0x490
    drivers/usb/core/driver.c:272 really_probe+0xf20/0x20b0 drivers/base/dd.c:529
    driver_probe_device+0x293/0x390 drivers/base/dd.c:701 __device_attach_driver+0x63f/0x830
    drivers/base/dd.c:807 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431 __device_attach+0x4e2/0x7f0
    drivers/base/dd.c:873 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920 bus_probe_device+0x177/0x3d0
    drivers/base/bus.c:491 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680 usb_new_device+0x1bd4/0x2a30
    drivers/usb/core/hub.c:2554 hub_port_connect drivers/usb/core/hub.c:5208 [inline] hub_port_connect_change
    drivers/usb/core/hub.c:5348 [inline] port_event drivers/usb/core/hub.c:5494 [inline]
    hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576 process_one_work+0x1688/0x2140 kernel/workqueue.c:2269
    worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415 kthread+0x551/0x590 kernel/kthread.c:292
    ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 Local variable ----buf.i87@smsc75xx_bind created at:
    __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline] smsc75xx_wait_ready
    drivers/net/usb/smsc75xx.c:968 [inline] smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482
    __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline] smsc75xx_wait_ready
    drivers/net/usb/smsc75xx.c:968 [inline] smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482 This
    issue is caused because usbnet_read_cmd() reads less bytes than requested (zero byte in the reproducer).
    In this case, 'buf' is not properly filled. This patch fixes the issue by returning -ENODATA if
    usbnet_read_cmd() reads less bytes than requested. (CVE-2023-52528)

  - In the Linux kernel, the following vulnerability has been resolved: HID: sony: Fix a potential memory leak
    in sony_probe() If an error occurs after a successful usb_alloc_urb() call, usb_free_urb() should be
    called. (CVE-2023-52529)

  - In the Linux kernel, the following vulnerability has been resolved: net: mana: Fix TX CQE error handling
    For an unknown TX CQE error type (probably from a newer hardware), still free the SKB, update the queue
    tail, etc., otherwise the accounting will be wrong. Also, TX errors can be triggered by injecting
    corrupted packets, so replace the WARN_ONCE to ratelimited error logging. (CVE-2023-52532)

  - In the Linux kernel, the following vulnerability has been resolved: arm64: dts: qcom: sdm845-db845c: Mark
    cont splash memory region as reserved Adding a reserved memory region for the framebuffer memory (the
    splash memory region set up by the bootloader). It fixes a kernel panic (arm-smmu: Unhandled context fault
    at this particular memory region) reported on DB845c running v5.10.y. (CVE-2023-52561)

  - In the Linux kernel, the following vulnerability has been resolved: drm/meson: fix memory leak on
    ->hpd_notify callback The EDID returned by drm_bridge_get_edid() needs to be freed. (CVE-2023-52563)

  - In the Linux kernel, the following vulnerability has been resolved: Revert tty: n_gsm: fix UAF in
    gsm_cleanup_mux This reverts commit 9b9c8195f3f0d74a826077fc1c01b9ee74907239. The commit above is
    reverted as it did not solve the original issue. gsm_cleanup_mux() tries to free up the virtual ttys by
    calling gsm_dlci_release() for each available DLCI. There, dlci_put() is called to decrease the reference
    counter for the DLCI via tty_port_put() which finally calls gsm_dlci_free(). This already clears the
    pointer which is being checked in gsm_cleanup_mux() before calling gsm_dlci_release(). Therefore, it is
    not necessary to clear this pointer in gsm_cleanup_mux() as done in the reverted commit. The commit
    introduces a null pointer dereference: <TASK> ? __die+0x1f/0x70 ? page_fault_oops+0x156/0x420 ?
    search_exception_tables+0x37/0x50 ? fixup_exception+0x21/0x310 ? exc_page_fault+0x69/0x150 ?
    asm_exc_page_fault+0x26/0x30 ? tty_port_put+0x19/0xa0 gsmtty_cleanup+0x29/0x80 [n_gsm]
    release_one_tty+0x37/0xe0 process_one_work+0x1e6/0x3e0 worker_thread+0x4c/0x3d0 ?
    __pfx_worker_thread+0x10/0x10 kthread+0xe1/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x50 ?
    __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> The actual issue is that nothing guards
    dlci_put() from being called multiple times while the tty driver was triggered but did not yet finished
    calling gsm_dlci_free(). (CVE-2023-52564)

  - In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential use after free
    in nilfs_gccache_submit_read_data() In nilfs_gccache_submit_read_data(), brelse(bh) is called to drop the
    reference count of bh when the call to nilfs_dat_translate() fails. If the reference count hits 0 and its
    owner page gets unlocked, bh may be freed. However, bh->b_page is dereferenced to put the page after that,
    which may result in a use-after-free bug. This patch moves the release operation after unlocking and
    putting the page. NOTE: The function in question is only called in GC, and in combination with current
    userland tools, address translation using DAT does not occur in that function, so the code path that
    causes this issue will not be executed. However, it is possible to run that code path by intentionally
    modifying the userland GC library or by calling the GC ioctl directly. [[email protected]: NOTE
    added to the commit log] (CVE-2023-52566)

  - In the Linux kernel, the following vulnerability has been resolved: serial: 8250_port: Check IRQ data
    before use In case the leaf driver wants to use IRQ polling (irq = 0) and IIR register shows that an
    interrupt happened in the 8250 hardware the IRQ data can be NULL. In such a case we need to skip the wake
    event as we came to this path from the timer interrupt and quite likely system is already awake. Without
    this fix we have got an Oops: serial8250: ttyS0 at I/O 0x3f8 (irq = 0, base_baud = 115200) is a 16550A ...
    BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: 0010:serial8250_handle_irq+0x7c/0x240
    Call Trace: ? serial8250_handle_irq+0x7c/0x240 ? __pfx_serial8250_timeout+0x10/0x10 (CVE-2023-52567)

  - In the Linux kernel, the following vulnerability has been resolved: btrfs: remove BUG() after failure to
    insert delayed dir index item Instead of calling BUG() when we fail to insert a delayed dir index item
    into the delayed node's tree, we can just release all the resources we have allocated/acquired before and
    return the error to the caller. This is fine because all existing call chains undo anything they have done
    before calling btrfs_insert_delayed_dir_index() or BUG_ON (when creating pending snapshots in the
    transaction commit path). So remove the BUG() call and do proper error handling. This relates to a syzbot
    report linked below, but does not fix it because it only prevents hitting a BUG(), it does not fix the
    issue where somehow we attempt to use twice the same index number for different index items.
    (CVE-2023-52569)

  - In the Linux kernel, the following vulnerability has been resolved: team: fix null-ptr-deref when team
    device type is changed Get a null-ptr-deref bug as follows with reproducer [1]. BUG: kernel NULL pointer
    dereference, address: 0000000000000228 ... RIP: 0010:vlan_dev_hard_header+0x35/0x140 [8021q] ... Call
    Trace: <TASK> ? __die+0x24/0x70 ? page_fault_oops+0x82/0x150 ? exc_page_fault+0x69/0x150 ?
    asm_exc_page_fault+0x26/0x30 ? vlan_dev_hard_header+0x35/0x140 [8021q] ? vlan_dev_hard_header+0x8e/0x140
    [8021q] neigh_connected_output+0xb2/0x100 ip6_finish_output2+0x1cb/0x520 ? nf_hook_slow+0x43/0xc0 ?
    ip6_mtu+0x46/0x80 ip6_finish_output+0x2a/0xb0 mld_sendpack+0x18f/0x250 mld_ifc_work+0x39/0x160
    process_one_work+0x1e6/0x3f0 worker_thread+0x4d/0x2f0 ? __pfx_worker_thread+0x10/0x10 kthread+0xe5/0x120 ?
    __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 [1]
    $ teamd -t team0 -d -c '{runner: {name: loadbalance}}' $ ip link add name t-dummy type dummy $ ip
    link add link t-dummy name t-dummy.100 type vlan id 100 $ ip link add name t-nlmon type nlmon $ ip link
    set t-nlmon master team0 $ ip link set t-nlmon nomaster $ ip link set t-dummy up $ ip link set team0 up $
    ip link set t-dummy.100 down $ ip link set t-dummy.100 master team0 When enslave a vlan device to team
    device and team device type is changed from non-ether to ether, header_ops of team device is changed to
    vlan_header_ops. That is incorrect and will trigger null-ptr-deref for vlan->real_dev in
    vlan_dev_hard_header() because team device is not a vlan device. Cache eth_header_ops in team_setup(),
    then assign cached header_ops to header_ops of team net device when its type is changed from non-ether to
    ether to fix the bug. (CVE-2023-52574)

  - Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
    (CVE-2023-52575, CVE-2023-52605)

  - In the Linux kernel, the following vulnerability has been resolved: x86/mm, kexec, ima: Use
    memblock_free_late() from ima_free_kexec_buffer() The code calling ima_free_kexec_buffer() runs long after
    the memblock allocator has already been torn down, potentially resulting in a use after free in
    memblock_isolate_range(). With KASAN or KFENCE, this use after free will result in a BUG from the idle
    task, and a subsequent kernel panic. Switch ima_free_kexec_buffer() over to memblock_free_late() to avoid
    that bug. (CVE-2023-52576)

  - In the Linux kernel, the following vulnerability has been resolved: netfs: Only call folio_start_fscache()
    one time for each folio If a network filesystem using netfs implements a clamp_length() function, it can
    set subrequest lengths smaller than a page size. When we loop through the folios in
    netfs_rreq_unlock_folios() to set any folios to be written back, we need to make sure we only call
    folio_start_fscache() once for each folio. Otherwise, this simple testcase: mount -o
    fsc,rsize=1024,wsize=1024 127.0.0.1:/export /mnt/nfs dd if=/dev/zero of=/mnt/nfs/file.bin bs=4096 count=1
    1+0 records in 1+0 records out 4096 bytes (4.1 kB, 4.0 KiB) copied, 0.0126359 s, 324 kB/s echo 3 >
    /proc/sys/vm/drop_caches cat /mnt/nfs/file.bin > /dev/null will trigger an oops similar to the following:
    page dumped because: VM_BUG_ON_FOLIO(folio_test_private_2(folio)) ------------[ cut here ]------------
    kernel BUG at include/linux/netfs.h:44! ... CPU: 5 PID: 134 Comm: kworker/u16:5 Kdump: loaded Not tainted
    6.4.0-rc5 ... RIP: 0010:netfs_rreq_unlock_folios+0x68e/0x730 [netfs] ... Call Trace:
    netfs_rreq_assess+0x497/0x660 [netfs] netfs_subreq_terminated+0x32b/0x610 [netfs]
    nfs_netfs_read_completion+0x14e/0x1a0 [nfs] nfs_read_completion+0x2f9/0x330 [nfs] rpc_free_task+0x72/0xa0
    [sunrpc] rpc_async_release+0x46/0x70 [sunrpc] process_one_work+0x3bd/0x710 worker_thread+0x89/0x610
    kthread+0x181/0x1c0 ret_from_fork+0x29/0x50 (CVE-2023-52582)

  - 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: 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: reiserfs: Avoid touching renamed
    directory if parent does not change The VFS will not be locking moved directory if its parent does not
    change. Change reiserfs rename code to avoid touching renamed directory if its parent does not change as
    without locking that can corrupt the filesystem. (CVE-2023-52591)

  - 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: 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)

  - In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Check mailbox/SMT
    channel for consistency On reception of a completion interrupt the shared memory area is accessed to
    retrieve the message header at first and then, if the message sequence number identifies a transaction
    which is still pending, the related payload is fetched too. When an SCMI command times out the channel
    ownership remains with the platform until eventually a late reply is received and, as a consequence, any
    further transmission attempt remains pending, waiting for the channel to be relinquished by the platform.
    Once that late reply is received the channel ownership is given back to the agent and any pending request
    is then allowed to proceed and overwrite the SMT area of the just delivered late reply; then the wait for
    the reply to the new request starts. It has been observed that the spurious IRQ related to the late reply
    can be wrongly associated with the freshly enqueued request: when that happens the SCMI stack in-flight
    lookup procedure is fooled by the fact that the message header now present in the SMT area is related to
    the new pending transaction, even though the real reply has still to arrive. This race-condition on the
    A2P channel can be detected by looking at the channel status bits: a genuine reply from the platform will
    have set the channel free bit before triggering the completion IRQ. Add a consistency check to validate
    such condition in the A2P ISR. (CVE-2023-52608)

  - In the Linux kernel, the following vulnerability has been resolved: crypto: scomp - fix req->dst buffer
    overflow The req->dst buffer size should be checked before copying from the scomp_scratch->dst to avoid
    req->dst buffer overflow problem. (CVE-2023-52612)

  - In the Linux kernel, the following vulnerability has been resolved: hwrng: core - Fix page fault dead lock
    on mmap-ed hwrng There is a dead-lock in the hwrng device read path. This triggers when the user reads
    from /dev/hwrng into memory also mmap-ed from /dev/hwrng. The resulting page fault triggers a recursive
    read which then dead-locks. Fix this by using a stack buffer when calling copy_to_user. (CVE-2023-52615)

  - In the Linux kernel, the following vulnerability has been resolved: PCI: switchtec: Fix stdev_release()
    crash after surprise hot remove A PCI device hot removal may occur while stdev->cdev is held open. The
    call to stdev_release() then happens during close or exit, at a point way past switchtec_pci_remove().
    Otherwise the last ref would vanish with the trailing put_device(), just before return. At that later
    point in time, the devm cleanup has already removed the stdev->mmio_mrpc mapping. Also, the stdev->pdev
    reference was not a counted one. Therefore, in DMA mode, the iowrite32() in stdev_release() will cause a
    fatal page fault, and the subsequent dma_free_coherent(), if reached, would pass a stale &stdev->pdev->dev
    pointer. Fix by moving MRPC DMA shutdown into switchtec_pci_remove(), after stdev_kill(). Counting the
    stdev->pdev ref is now optional, but may prevent future accidents. Reproducible via the script at
    https://lore.kernel.org/r/[email protected] (CVE-2023-52617)

  - In the Linux kernel, the following vulnerability has been resolved: pstore/ram: Fix crash when setting
    number of cpus to an odd number When the number of cpu cores is adjusted to 7 or other odd numbers, the
    zone size will become an odd number. The address of the zone will become: addr of zone0 = BASE addr of
    zone1 = BASE + zone_size addr of zone2 = BASE + zone_size*2 ... The address of zone1/3/5/7 will be mapped
    to non-alignment va. Eventually crashes will occur when accessing these va. So, use ALIGN_DOWN() to make
    sure the zone size is even to avoid this bug. (CVE-2023-52619)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Check rcu_read_lock_trace_held()
    before calling bpf map helpers These three bpf_map_{lookup,update,delete}_elem() helpers are also
    available for sleepable bpf program, so add the corresponding lock assertion for sleepable bpf program,
    otherwise the following warning will be reported when a sleepable bpf program manipulates bpf map under
    interpreter mode (aka bpf_jit_enable=0): WARNING: CPU: 3 PID: 4985 at kernel/bpf/helpers.c:40 ...... CPU:
    3 PID: 4985 Comm: test_progs Not tainted 6.6.0+ #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
    ...... RIP: 0010:bpf_map_lookup_elem+0x54/0x60 ...... Call Trace: <TASK> ? __warn+0xa5/0x240 ?
    bpf_map_lookup_elem+0x54/0x60 ? report_bug+0x1ba/0x1f0 ? handle_bug+0x40/0x80 ? exc_invalid_op+0x18/0x50 ?
    asm_exc_invalid_op+0x1b/0x20 ? __pfx_bpf_map_lookup_elem+0x10/0x10 ?
    rcu_lockdep_current_cpu_online+0x65/0xb0 ? rcu_is_watching+0x23/0x50 ? bpf_map_lookup_elem+0x54/0x60 ?
    __pfx_bpf_map_lookup_elem+0x10/0x10 ___bpf_prog_run+0x513/0x3b70 __bpf_prog_run32+0x9d/0xd0 ?
    __bpf_prog_enter_sleepable_recur+0xad/0x120 ? __bpf_prog_enter_sleepable_recur+0x3e/0x120
    bpf_trampoline_6442580665+0x4d/0x1000 __x64_sys_getpgid+0x5/0x30 ? do_syscall_64+0x36/0xb0
    entry_SYSCALL_64_after_hwframe+0x6e/0x76 </TASK> (CVE-2023-52621)

  - In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix a suspicious RCU usage
    warning I received the following warning while running cthon against an ontap server running pNFS: [
    57.202521] ============================= [ 57.202522] WARNING: suspicious RCU usage [ 57.202523]
    6.7.0-rc3-g2cc14f52aeb7 #41492 Not tainted [ 57.202525] ----------------------------- [ 57.202525]
    net/sunrpc/xprtmultipath.c:349 RCU-list traversed in non-reader section!! [ 57.202527] other info that
    might help us debug this: [ 57.202528] rcu_scheduler_active = 2, debug_locks = 1 [ 57.202529] no locks
    held by test5/3567. [ 57.202530] stack backtrace: [ 57.202532] CPU: 0 PID: 3567 Comm: test5 Not tainted
    6.7.0-rc3-g2cc14f52aeb7 #41492 5b09971b4965c0aceba19f3eea324a4a806e227e [ 57.202534] Hardware name: QEMU
    Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022 [ 57.202536] Call Trace: [ 57.202537] <TASK> [
    57.202540] dump_stack_lvl+0x77/0xb0 [ 57.202551] lockdep_rcu_suspicious+0x154/0x1a0 [ 57.202556]
    rpc_xprt_switch_has_addr+0x17c/0x190 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202596]
    rpc_clnt_setup_test_and_add_xprt+0x50/0x180 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202621]
    ? rpc_clnt_add_xprt+0x254/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202646]
    rpc_clnt_add_xprt+0x27a/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202671] ?
    __pfx_rpc_clnt_setup_test_and_add_xprt+0x10/0x10 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [
    57.202696] nfs4_pnfs_ds_connect+0x345/0x760 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202728]
    ? __pfx_nfs4_test_session_trunk+0x10/0x10 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202754]
    nfs4_fl_prepare_ds+0x75/0xc0 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a] [
    57.202760] filelayout_write_pagelist+0x4a/0x200 [nfs_layout_nfsv41_files
    e3a4187f18ae8a27b630f9feae6831b584a9360a] [ 57.202765] pnfs_generic_pg_writepages+0xbe/0x230 [nfsv4
    c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202788] __nfs_pageio_add_request+0x3fd/0x520 [nfs
    6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202813] nfs_pageio_add_request+0x18b/0x390 [nfs
    6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202831] nfs_do_writepage+0x116/0x1e0 [nfs
    6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202849] nfs_writepages_callback+0x13/0x30 [nfs
    6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202866] write_cache_pages+0x265/0x450 [ 57.202870] ?
    __pfx_nfs_writepages_callback+0x10/0x10 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202891]
    nfs_writepages+0x141/0x230 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202913]
    do_writepages+0xd2/0x230 [ 57.202917] ? filemap_fdatawrite_wbc+0x5c/0x80 [ 57.202921]
    filemap_fdatawrite_wbc+0x67/0x80 [ 57.202924] filemap_write_and_wait_range+0xd9/0x170 [ 57.202930]
    nfs_wb_all+0x49/0x180 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202947]
    nfs4_file_flush+0x72/0xb0 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202969]
    __se_sys_close+0x46/0xd0 [ 57.202972] do_syscall_64+0x68/0x100 [ 57.202975] ? do_syscall_64+0x77/0x100 [
    57.202976] ? do_syscall_64+0x77/0x100 [ 57.202979] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 57.202982]
    RIP: 0033:0x7fe2b12e4a94 [ 57.202985] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00
    90 f3 0f 1e fa 80 3d d5 18 0e 00 00 74 13 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 44 c3 0f 1f 00 48 83
    ec 18 89 7c 24 0c e8 c3 [ 57.202987] RSP: 002b:00007ffe857ddb38 EFLAGS: 00000202 ORIG_RAX:
    0000000000000003 [ 57.202989] RAX: ffffffffffffffda RBX: 00007ffe857dfd68 RCX: 00007fe2b12e4a94 [
    57.202991] RDX: 0000000000002000 RSI: 00007ffe857ddc40 RDI: 0000000000000003 [ 57.202992] RBP:
    00007ffe857dfc50 R08: 7fffffffffffffff R09: 0000000065650f49 [ 57.202993] R10: 00007f ---truncated---
    (CVE-2023-52623)

  - In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7091r: Allow users to
    configure device events AD7091R-5 devices are supported by the ad7091r-5 driver together with the
    ad7091r-base driver. Those drivers declared iio events for notifying user space when ADC readings fall
    bellow the thresholds of low limit registers or above the values set in high limit registers. However, to
    configure iio events and their thresholds, a set of callback functions must be implemented and those were
    not present until now. The consequence of trying to configure ad7091r-5 events without the proper callback
    functions was a null pointer dereference in the kernel because the pointers to the callback functions were
    not set. Implement event configuration callbacks allowing users to read/write event thresholds and
    enable/disable event generation. Since the event spec structs are generic to AD7091R devices, also move
    those from the ad7091r-5 driver the base driver so they can be reused when support for ad7091r-2/-4/-8 be
    added. (CVE-2023-52627)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nftables: exthdr: fix
    4-byte stack OOB write If priv->len is a multiple of 4, then dst[len / 4] can write past the destination
    array which leads to stack corruption. This construct is necessary to clean the remainder of the register
    in case ->len is NOT a multiple of the register size, so make it conditional just like nft_payload.c does.
    The bug was added in 4.1 cycle and then copied/inherited when tcp/sctp and ip option support was added.
    Bug reported by Zero Day Initiative project (ZDI-CAN-21950, ZDI-CAN-21951, ZDI-CAN-21961).
    (CVE-2023-52628)

  - In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix lock dependency
    warning with srcu ====================================================== WARNING: possible circular
    locking dependency detected 6.5.0-kfd-yangp #2289 Not tainted
    ------------------------------------------------------ kworker/0:2/996 is trying to acquire lock:
    (srcu){.+.+}-{0:0}, at: __synchronize_srcu+0x5/0x1a0 but task is already holding lock:
    ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}, at: process_one_work+0x211/0x560 which lock
    already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3
    ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0
    svm_range_list_lock_and_flush_work+0x3d/0x110 [amdgpu] svm_range_set_attr+0xd6/0x14c0 [amdgpu]
    kfd_ioctl+0x1d1/0x630 [amdgpu] __x64_sys_ioctl+0x88/0xc0 -> #2 (&info->lock#2){+.+.}-{3:3}:
    __mutex_lock+0x99/0xc70 amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu]
    restore_process_helper+0x22/0x80 [amdgpu] restore_process_worker+0x2d/0xa0 [amdgpu]
    process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0 -> #1
    ((work_completion)(&(&process->restore_work)->work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0
    __cancel_work_timer+0x12c/0x1c0 kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu]
    __mmu_notifier_release+0xad/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 do_exit+0x322/0xb90
    do_group_exit+0x37/0xa0 __x64_sys_exit_group+0x18/0x20 do_syscall_64+0x38/0x80 -> #0 (srcu){.+.+}-{0:0}:
    __lock_acquire+0x1521/0x2510 lock_sync+0x5f/0x90 __synchronize_srcu+0x4f/0x1a0
    __mmu_notifier_release+0x128/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120
    svm_range_deferred_list_work+0x19f/0x350 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0
    other info that might help us debug this: Chain exists of: srcu --> &info->lock#2 -->
    (work_completion)(&svms->deferred_list_work) Possible unsafe locking scenario: CPU0 CPU1 ---- ----
    lock((work_completion)(&svms->deferred_list_work)); lock(&info->lock#2);
    lock((work_completion)(&svms->deferred_list_work)); sync(srcu); (CVE-2023-52632)

  - In the Linux kernel, the following vulnerability has been resolved: libceph: just wait for more data to be
    available on the socket A short read may occur while reading the message footer from the socket. Later,
    when the socket is ready for another read, the messenger invokes all read_partial_*() handlers, including
    read_partial_sparse_msg_data(). The expectation is that read_partial_sparse_msg_data() would bail,
    allowing the messenger to invoke read_partial() for the footer and pick up where it left off. However
    read_partial_sparse_msg_data() violates that and ends up calling into the state machine in the OSD client.
    The sparse-read state machine assumes that it's a new op and interprets some piece of the footer as the
    sparse-read header and returns bogus extents/data length, etc. To determine whether
    read_partial_sparse_msg_data() should bail, let's reuse cursor->total_resid. Because once it reaches to
    zero that means all the extents and data have been successfully received in last read, else it could break
    out when partially reading any of the extents and data. And then osd_sparse_read() could continue where it
    left off. [ idryomov: changelog ] (CVE-2023-52636)

  - In the Linux kernel, the following vulnerability has been resolved: can: j1939: Fix UAF in
    j1939_sk_match_filter during setsockopt(SO_J1939_FILTER) Lock jsk->sk to prevent UAF when setsockopt(...,
    SO_J1939_FILTER, ...) modifies jsk->filters while receiving packets. Following trace was seen on affected
    system: ================================================================== BUG: KASAN: slab-use-after-free
    in j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] Read of size 4 at addr ffff888012144014 by task
    j1939/350 CPU: 0 PID: 350 Comm: j1939 Tainted: G W OE 6.5.0-rc5 #1 Hardware name: QEMU Standard PC (i440FX
    + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: print_report+0xd3/0x620 ?
    kasan_complete_mode_report_info+0x7d/0x200 ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
    kasan_report+0xc2/0x100 ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] __asan_load4+0x84/0xb0
    j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] j1939_sk_recv+0x20b/0x320 [can_j1939] ?
    __kasan_check_write+0x18/0x20 ? __pfx_j1939_sk_recv+0x10/0x10 [can_j1939] ? j1939_simple_recv+0x69/0x280
    [can_j1939] ? j1939_ac_recv+0x5e/0x310 [can_j1939] j1939_can_recv+0x43f/0x580 [can_j1939] ?
    __pfx_j1939_can_recv+0x10/0x10 [can_j1939] ? raw_rcv+0x42/0x3c0 [can_raw] ? __pfx_j1939_can_recv+0x10/0x10
    [can_j1939] can_rcv_filter+0x11f/0x350 [can] can_receive+0x12f/0x190 [can] ? __pfx_can_rcv+0x10/0x10 [can]
    can_rcv+0xdd/0x130 [can] ? __pfx_can_rcv+0x10/0x10 [can] __netif_receive_skb_one_core+0x13d/0x150 ?
    __pfx___netif_receive_skb_one_core+0x10/0x10 ? __kasan_check_write+0x18/0x20 ?
    _raw_spin_lock_irq+0x8c/0xe0 __netif_receive_skb+0x23/0xb0 process_backlog+0x107/0x260
    __napi_poll+0x69/0x310 net_rx_action+0x2a1/0x580 ? __pfx_net_rx_action+0x10/0x10 ?
    __pfx__raw_spin_lock+0x10/0x10 ? handle_irq_event+0x7d/0xa0 __do_softirq+0xf3/0x3f8 do_softirq+0x53/0x80
    </IRQ> <TASK> __local_bh_enable_ip+0x6e/0x70 netif_rx+0x16b/0x180 can_send+0x32b/0x520 [can] ?
    __pfx_can_send+0x10/0x10 [can] ? __check_object_size+0x299/0x410 raw_sendmsg+0x572/0x6d0 [can_raw] ?
    __pfx_raw_sendmsg+0x10/0x10 [can_raw] ? apparmor_socket_sendmsg+0x2f/0x40 ? __pfx_raw_sendmsg+0x10/0x10
    [can_raw] sock_sendmsg+0xef/0x100 sock_write_iter+0x162/0x220 ? __pfx_sock_write_iter+0x10/0x10 ?
    __rtnl_unlock+0x47/0x80 ? security_file_permission+0x54/0x320 vfs_write+0x6ba/0x750 ?
    __pfx_vfs_write+0x10/0x10 ? __fget_light+0x1ca/0x1f0 ? __rcu_read_unlock+0x5b/0x280 ksys_write+0x143/0x170
    ? __pfx_ksys_write+0x10/0x10 ? __kasan_check_read+0x15/0x20 ? fpregs_assert_state_consistent+0x62/0x70
    __x64_sys_write+0x47/0x60 do_syscall_64+0x60/0x90 ? do_syscall_64+0x6d/0x90 ? irqentry_exit+0x3f/0x50 ?
    exc_page_fault+0x79/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 348:
    kasan_save_stack+0x2a/0x50 kasan_set_track+0x29/0x40 kasan_save_alloc_info+0x1f/0x30
    __kasan_kmalloc+0xb5/0xc0 __kmalloc_node_track_caller+0x67/0x160 j1939_sk_setsockopt+0x284/0x450
    [can_j1939] __sys_setsockopt+0x15c/0x2f0 __x64_sys_setsockopt+0x6b/0x80 do_syscall_64+0x60/0x90
    entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 349: kasan_save_stack+0x2a/0x50
    kasan_set_track+0x29/0x40 kasan_save_free_info+0x2f/0x50 __kasan_slab_free+0x12e/0x1c0
    __kmem_cache_free+0x1b9/0x380 kfree+0x7a/0x120 j1939_sk_setsockopt+0x3b2/0x450 [can_j1939]
    __sys_setsockopt+0x15c/0x2f0 __x64_sys_setsockopt+0x6b/0x80 do_syscall_64+0x60/0x90
    entry_SYSCALL_64_after_hwframe+0x6e/0xd8 (CVE-2023-52637)

  - In the Linux kernel, the following vulnerability has been resolved: KVM: s390: vsie: fix race during
    shadow creation Right now it is possible to see gmap->private being zero in kvm_s390_vsie_gmap_notifier
    resulting in a crash. This is due to the fact that we add gmap->private == kvm after creation: static int
    acquire_gmap_shadow(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page) { [...] gmap =
    gmap_shadow(vcpu->arch.gmap, asce, edat); if (IS_ERR(gmap)) return PTR_ERR(gmap); gmap->private =
    vcpu->kvm; Let children inherit the private field of the parent. (CVE-2023-52639)

  - A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious
    actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL
    pointer dereference in the NVMe driver and causing kernel panic and a denial of service. (CVE-2023-6356)

  - A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious
    actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL
    pointer dereference in the NVMe driver, causing kernel panic and a denial of service. (CVE-2023-6535,
    CVE-2023-6536)

  - A null pointer dereference vulnerability was found in ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev() in
    drivers/net/wireless/ath/ath10k/wmi-tlv.c in the Linux kernel. This issue could be exploited to trigger a
    denial of service. (CVE-2023-7042)

  - A memory leak problem was found in ctnetlink_create_conntrack in net/netfilter/nf_conntrack_netlink.c in
    the Linux Kernel. This issue may allow a local attacker with CAP_NET_ADMIN privileges to cause a denial of
    service (DoS) attack due to a refcount overflow. (CVE-2023-7192)

  - A null pointer dereference flaw was found in the hugetlbfs_fill_super function in the Linux kernel
    hugetlbfs (HugeTLB pages) functionality. This issue may allow a local user to crash the system or
    potentially escalate their privileges on the system. (CVE-2024-0841)

  - This CVE was assigned by Intel. Please see CVE-2024-2201 on CVE.org for more information. (CVE-2024-2201)

  - NULL Pointer Dereference vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (net, bluetooth
    modules) allows Overflow Buffers. This vulnerability is associated with program files
    /net/bluetooth/rfcomm/core.C. This issue affects Linux kernel: v2.6.12-rc2. (CVE-2024-22099)

  - Integer Overflow or Wraparound vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (md, raid,
    raid5 modules) allows Forced Integer Overflow. (CVE-2024-23307)

  - In btrfs_get_root_ref in fs/btrfs/disk-io.c in the Linux kernel through 6.7.1, there can be an assertion
    failure and crash because a subvolume can be read out too soon after its root item is inserted upon
    subvolume creation. (CVE-2024-23850)

  - create_empty_lvol in drivers/mtd/ubi/vtbl.c in the Linux kernel through 6.7.4 can attempt to allocate zero
    bytes, and crash, because of a missing check for ubi->leb_size. (CVE-2024-25739)

  - Integer Overflow or Wraparound vulnerability in Linux kernel on x86 and ARM (md, raid, raid5 modules)
    allows Forced Integer Overflow. (CVE-2024-23307) (CVE-2024-25742)

  - 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: sched/membarrier: reduce the ability
    to hammer on sys_membarrier On some systems, sys_membarrier can be very expensive, causing overall
    slowdowns for everything. So put a lock on the path in order to serialize the accesses to prevent the
    ability for this to be called at too high of a frequency and saturate the machine. (CVE-2024-26602)

  - In the Linux kernel, the following vulnerability has been resolved: netfs, fscache: Prevent Oops in
    fscache_put_cache() This function dereferences cache and then checks if it's IS_ERR_OR_NULL(). Check
    first, then dereference. (CVE-2024-26612)

  - In the Linux kernel, the following vulnerability has been resolved: tcp: make sure init the accept_queue's
    spinlocks once When I run syz's reproduction C program locally, it causes the following issue:
    pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0! WARNING: CPU: 19 PID: 21160 at
    __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508) Hardware name: Red Hat KVM,
    BIOS 0.5.1 01/01/2011 RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
    Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7
    30 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90 RSP:
    0018:ffffa8d200604cb8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908
    RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900 RBP: ffff9d181cd5c280 R08:
    0000000000000000 R09: 00000000ffff7fff R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000
    R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000 FS: 00007fa110184640(0000)
    GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0 Call Trace: <IRQ> _raw_spin_unlock
    (kernel/locking/spinlock.c:186) inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321)
    inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c:1358) tcp_check_req
    (net/ipv4/tcp_minisocks.c:868) tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260) ip_protocol_deliver_rcu
    (net/ipv4/ip_input.c:205) ip_local_deliver_finish (net/ipv4/ip_input.c:234) __netif_receive_skb_one_core
    (net/core/dev.c:5529) process_backlog (./include/linux/rcupdate.h:779) __napi_poll (net/core/dev.c:6533)
    net_rx_action (net/core/dev.c:6604) __do_softirq (./arch/x86/include/asm/jump_label.h:27) do_softirq
    (kernel/softirq.c:454 kernel/softirq.c:441) </IRQ> <TASK> __local_bh_enable_ip (kernel/softirq.c:381)
    __dev_queue_xmit (net/core/dev.c:4374) ip_finish_output2 (./include/net/neighbour.h:540
    net/ipv4/ip_output.c:235) __ip_queue_xmit (net/ipv4/ip_output.c:535) __tcp_transmit_skb
    (net/ipv4/tcp_output.c:1462) tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469)
    tcp_rcv_state_process (net/ipv4/tcp_input.c:6657) tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929) __release_sock
    (./include/net/sock.h:1121 net/core/sock.c:2968) release_sock (net/core/sock.c:3536) inet_wait_for_connect
    (net/ipv4/af_inet.c:609) __inet_stream_connect (net/ipv4/af_inet.c:702) inet_stream_connect
    (net/ipv4/af_inet.c:748) __sys_connect (./include/linux/file.h:45 net/socket.c:2064) __x64_sys_connect
    (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070) do_syscall_64 (arch/x86/entry/common.c:51
    arch/x86/entry/common.c:82) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129) RIP:
    0033:0x7fa10ff05a3d Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 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 8b 0d ab a3 0e 00 f7 d8 64 89
    01 48 RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX:
    0000000020000054 RCX: 00007fa10ff05a3d RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003
    RBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11:
    0000000000000202 R12: 00007fa110184640 R13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20
    </TASK> The issue triggering process is analyzed as follows: Thread A Thread B tcp_v4_rcv //receive ack
    TCP packet inet_shutdown tcp_check_req tcp_disconnect //disconnect sock ... tcp_set_state(sk, TCP_CLOSE)
    inet_csk_complete_hashdance ... inet_csk_reqsk_queue_add ---truncated--- (CVE-2024-26614)

  - In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: always filter entire AP
    matrix The vfio_ap_mdev_filter_matrix function is called whenever a new adapter or domain is assigned to
    the mdev. The purpose of the function is to update the guest's AP configuration by filtering the matrix of
    adapters and domains assigned to the mdev. When an adapter or domain is assigned, only the APQNs
    associated with the APID of the new adapter or APQI of the new domain are inspected. If an APQN does not
    reference a queue device bound to the vfio_ap device driver, then it's APID will be filtered from the
    mdev's matrix when updating the guest's AP configuration. Inspecting only the APID of the new adapter or
    APQI of the new domain will result in passing AP queues through to a guest that are not bound to the
    vfio_ap device driver under certain circumstances. Consider the following: guest's AP configuration (all
    also assigned to the mdev's matrix): 14.0004 14.0005 14.0006 16.0004 16.0005 16.0006 unassign domain 4
    unbind queue 16.0005 assign domain 4 When domain 4 is re-assigned, since only domain 4 will be inspected,
    the APQNs that will be examined will be: 14.0004 16.0004 Since both of those APQNs reference queue devices
    that are bound to the vfio_ap device driver, nothing will get filtered from the mdev's matrix when
    updating the guest's AP configuration. Consequently, queue 16.0005 will get passed through despite not
    being bound to the driver. This violates the linux device model requirement that a guest shall only be
    given access to devices bound to the device driver facilitating their pass-through. To resolve this
    problem, every adapter and domain assigned to the mdev will be inspected when filtering the mdev's matrix.
    (CVE-2024-26620)

  - 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: nfsd: fix RELEASE_LOCKOWNER The test
    on so_count in nfsd4_release_lockowner() is nonsense and harmful. Revert to using check_for_locks(),
    changing that to not sleep. First: harmful. As is documented in the kdoc comment for
    nfsd4_release_lockowner(), the test on so_count can transiently return a false positive resulting in a
    return of NFS4ERR_LOCKS_HELD when in fact no locks are held. This is clearly a protocol violation and with
    the Linux NFS client it can cause incorrect behaviour. If RELEASE_LOCKOWNER is sent while some other
    thread is still processing a LOCK request which failed because, at the time that request was received, the
    given owner held a conflicting lock, then the nfsd thread processing that LOCK request can hold a
    reference (conflock) to the lock owner that causes nfsd4_release_lockowner() to return an incorrect error.
    The Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because it never sends NFS4_RELEASE_LOCKOWNER
    without first releasing any locks, so it knows that the error is impossible. It assumes the lock owner was
    in fact released so it feels free to use the same lock owner identifier in some later locking request.
    When it does reuse a lock owner identifier for which a previous RELEASE failed, it will naturally use a
    lock_seqid of zero. However the server, which didn't release the lock owner, will expect a larger
    lock_seqid and so will respond with NFS4ERR_BAD_SEQID. So clearly it is harmful to allow a false positive,
    which testing so_count allows. The test is nonsense because ... well... it doesn't mean anything. so_count
    is the sum of three different counts. 1/ the set of states listed on so_stateids 2/ the set of active vfs
    locks owned by any of those states 3/ various transient counts such as for conflicting locks. When it is
    tested against '2' it is clear that one of these is the transient reference obtained by
    find_lockowner_str_locked(). It is not clear what the other one is expected to be. In practice, the count
    is often 2 because there is precisely one state on so_stateids. If there were more, this would fail. In my
    testing I see two circumstances when RELEASE_LOCKOWNER is called. In one case, CLOSE is called before
    RELEASE_LOCKOWNER. That results in all the lock states being removed, and so the lockowner being discarded
    (it is removed when there are no more references which usually happens when the lock state is discarded).
    When nfsd4_release_lockowner() finds that the lock owner doesn't exist, it returns success. The other case
    shows an so_count of '2' and precisely one state listed in so_stateid. It appears that the Linux client
    uses a separate lock owner for each file resulting in one lock state per lock owner, so this test on '2'
    is safe. For another client it might not be safe. So this patch changes check_for_locks() to use the
    (newish) find_any_file_locked() so that it doesn't take a reference on the nfs4_file and so never calls
    nfsd_file_put(), and so never sleeps. With this check is it safe to restore the use of check_for_locks()
    rather than testing so_count against the mysterious '2'. (CVE-2024-26629)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: disallow
    anonymous set with timeout flag Anonymous sets are never used with timeout from userspace, reject this.
    Exception to this rule is NFT_SET_EVAL to ensure legacy meters still work. (CVE-2024-26642)

  - In the Linux kernel, the following vulnerability has been resolved: tracing: Ensure visibility when
    inserting an element into tracing_map Running the following two commands in parallel on a multi-processor
    AArch64 machine can sporadically produce an unexpected warning about duplicate histogram entries: $ while
    true; do echo hist:key=id.syscall:val=hitcount > \
    /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger cat
    /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist sleep 0.001 done $ stress-ng --sysbadaddr
    $(nproc) The warning looks as follows: [ 2911.172474] ------------[ cut here ]------------ [ 2911.173111]
    Duplicates detected: 1 [ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracing_map.c:983
    tracing_map_sort_entries+0x3e0/0x408 [ 2911.174702] Modules linked in: iscsi_ibft(E) iscsi_boot_sysfs(E)
    rfkill(E) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E)
    qemu_fw_cfg(E) button(E) fuse(E) efi_pstore(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) aes_ce_blk(E)
    aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E)
    sm4_ce_ccm(E) sm4_ce(E) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E)
    sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth(E) t10_pi(E) sg(E) scsi_mod(E)
    scsi_common(E) efivarfs(E) [ 2911.174738] Unloaded tainted modules: cppc_cpufreq(E):1 [ 2911.180985] CPU:
    2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2
    1b58bbb22c97e4399dc09f92d309344f69c44a01 [ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0
    11/1/2018 [ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2911.184038] pc
    : tracing_map_sort_entries+0x3e0/0x408 [ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408 [
    2911.185310] sp : ffff8000a1513900 [ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27:
    0000000000000001 [ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008 [
    2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180 [ 2911.188310] x20:
    ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff [ 2911.189160] x17: 0000000000000000 x16:
    0000000000000000 x15: ffff8000a15134b8 [ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12:
    5b5d313131333731 [ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c [
    2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8 [ 2911.192554] x5 :
    ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000 [ 2911.193404] x2 : 0000000000000000 x1 :
    0000000000000000 x0 : ffff0003ff254480 [ 2911.194259] Call trace: [ 2911.194626]
    tracing_map_sort_entries+0x3e0/0x408 [ 2911.195220] hist_show+0x124/0x800 [ 2911.195692]
    seq_read_iter+0x1d4/0x4e8 [ 2911.196193] seq_read+0xe8/0x138 [ 2911.196638] vfs_read+0xc8/0x300 [
    2911.197078] ksys_read+0x70/0x108 [ 2911.197534] __arm64_sys_read+0x24/0x38 [ 2911.198046]
    invoke_syscall+0x78/0x108 [ 2911.198553] el0_svc_common.constprop.0+0xd0/0xf8 [ 2911.199157]
    do_el0_svc+0x28/0x40 [ 2911.199613] el0_svc+0x40/0x178 [ 2911.200048] el0t_64_sync_handler+0x13c/0x158 [
    2911.200621] el0t_64_sync+0x1a8/0x1b0 [ 2911.201115] ---[ end trace 0000000000000000 ]--- The problem
    appears to be caused by CPU reordering of writes issued from __tracing_map_insert(). The check for the
    presence of an element with a given key in this function is: val = READ_ONCE(entry->val); if (val &&
    keys_match(key, val->key, map->key_size)) ... The write of a new entry is: elt = get_free_elt(map);
    memcpy(elt->key, key, map->key_size); entry->val = elt; The memcpy(elt->key, key, map->key_size); and
    entry->val = elt; stores may become visible in the reversed order on another CPU. This second CPU might
    then incorrectly determine that a new key doesn't match an already present val->key and subse
    ---truncated--- (CVE-2024-26645)

  - In the Linux kernel, the following vulnerability has been resolved: thermal: intel: hfi: Add syscore
    callbacks for system-wide PM The kernel allocates a memory buffer and provides its location to the
    hardware, which uses it to update the HFI table. This allocation occurs during boot and remains constant
    throughout runtime. When resuming from hibernation, the restore kernel allocates a second memory buffer
    and reprograms the HFI hardware with the new location as part of a normal boot. The location of the second
    memory buffer may differ from the one allocated by the image kernel. When the restore kernel transfers
    control to the image kernel, its HFI buffer becomes invalid, potentially leading to memory corruption if
    the hardware writes to it (the hardware continues to use the buffer from the restore kernel). It is also
    possible that the hardware forgets the address of the memory buffer when resuming from deep suspend.
    Memory corruption may also occur in such a scenario. To prevent the described memory corruption, disable
    HFI when preparing to suspend or hibernate. Enable it when resuming. Add syscore callbacks to handle the
    package of the boot CPU (packages of non-boot CPUs are handled via CPU offline). Syscore ops always run on
    the boot CPU. Additionally, HFI only needs to be disabled during deep suspend and hibernation. Syscore
    ops only run in these cases. [ rjw: Comment adjustment, subject and changelog edits ] (CVE-2024-26646)

  - In the Linux kernel, the following vulnerability has been resolved: sr9800: Add check for
    usbnet_get_endpoints Add check for usbnet_get_endpoints() and return the error if it fails in order to
    transfer the error. (CVE-2024-26651)

  - In the Linux kernel, the following vulnerability has been resolved: ALSA: sh: aica: reorder cleanup
    operations to avoid UAF bugs The dreamcastcard->timer could schedule the spu_dma_work and the spu_dma_work
    could also arm the dreamcastcard->timer. When the snd_pcm_substream is closing, the aica_channel will be
    deallocated. But it could still be dereferenced in the worker thread. The reason is that del_timer() will
    return directly regardless of whether the timer handler is running or not and the worker could be
    rescheduled in the timer handler. As a result, the UAF bug will happen. The racy situation is shown below:
    (Thread 1) | (Thread 2) snd_aicapcm_pcm_close() | ... | run_spu_dma() //worker | mod_timer() flush_work()
    | del_timer() | aica_period_elapsed() //timer kfree(dreamcastcard->channel) | schedule_work() |
    run_spu_dma() //worker ... | dreamcastcard->channel-> //USE In order to mitigate this bug and other
    possible corner cases, call mod_timer() conditionally in run_spu_dma(), then implement PCM sync_stop op to
    cancel both the timer and worker. The sync_stop op will be called from PCM core appropriately when needed.
    (CVE-2024-26654)

  - In the Linux kernel, the following vulnerability has been resolved: xhci: handle isoc Babble and Buffer
    Overrun events properly xHCI 4.9 explicitly forbids assuming that the xHC has released its ownership of a
    multi-TRB TD when it reports an error on one of the early TRBs. Yet the driver makes such assumption and
    releases the TD, allowing the remaining TRBs to be freed or overwritten by new TDs. The xHC should also
    report completion of the final TRB due to its IOC flag being set by us, regardless of prior errors. This
    event cannot be recognized if the TD has already been freed earlier, resulting in Transfer event TRB DMA
    ptr not part of current TD error message. Fix this by reusing the logic for processing isoc Transaction
    Errors. This also handles hosts which fail to report the final completion. Fix transfer length reporting
    on Babble errors. They may be caused by device malfunction, no guarantee that the buffer has been filled.
    (CVE-2024-26659)

  - In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Implement bounds
    check for stream encoder creation in DCN301 'stream_enc_regs' array is an array of
    dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the
    four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are
    0, 1, 2, and 3. The error message 'stream_enc_regs' 4 <= 5 below, is indicating that there is an attempt
    to access this array with an index of 5, which is out of bounds. This could lead to undefined behavior
    Here, eng_id is used as an index to access the stream_enc_regs array. If eng_id is 5, this would result in
    an out-of-bounds access on the stream_enc_regs array. Thus fixing Buffer overflow error in
    dcn301_stream_encoder_create reported by Smatch:
    drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn301/dcn301_resource.c:1011
    dcn301_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5 (CVE-2024-26660)

  - In the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) Fix out-of-bounds
    memory access Fix a bug that pdata->cpu_map[] is set before out-of-bounds check. The problem might be
    triggered on systems with more than 128 cores per package. (CVE-2024-26664)

  - In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: check for valid hw_pp in
    dpu_encoder_helper_phys_cleanup The commit 8b45a26f2ba9 (drm/msm/dpu: reserve cdm blocks for writeback in
    case of YUV output) introduced a smatch warning about another conditional block in
    dpu_encoder_helper_phys_cleanup() which had assumed hw_pp will always be valid which may not necessarily
    be true. Lets fix the other conditional block by making sure hw_pp is valid before dereferencing it.
    Patchwork: https://patchwork.freedesktop.org/patch/574878/ (CVE-2024-26667)

  - In the Linux kernel, the following vulnerability has been resolved: arm64: entry: fix
    ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD Currently the ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD workaround
    isn't quite right, as it is supposed to be applied after the last explicit memory access, but is
    immediately followed by an LDR. The ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD workaround is used to handle
    Cortex-A520 erratum 2966298 and Cortex-A510 erratum 3117295, which are described in: *
    https://developer.arm.com/documentation/SDEN2444153/0600/?lang=en *
    https://developer.arm.com/documentation/SDEN1873361/1600/?lang=en In both cases the workaround is
    described as: | If pagetable isolation is disabled, the context switch logic in the | kernel can be
    updated to execute the following sequence on affected | cores before exiting to EL0, and after all
    explicit memory accesses: | | 1. A non-shareable TLBI to any context and/or address, including | unused
    contexts or addresses, such as a `TLBI VALE1 Xzr`. | | 2. A DSB NSH to guarantee completion of the TLBI.
    The important part being that the TLBI+DSB must be placed after all explicit memory accesses.
    Unfortunately, as-implemented, the TLBI+DSB is immediately followed by an LDR, as we have: |
    alternative_if ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD | tlbi vale1, xzr | dsb nsh |
    alternative_else_nop_endif | alternative_if_not ARM64_UNMAP_KERNEL_AT_EL0 | ldr lr, [sp, #S_LR] | add sp,
    sp, #PT_REGS_SIZE // restore sp | eret | alternative_else_nop_endif | | [ ... KPTI exception return path
    ... ] This patch fixes this by reworking the logic to place the TLBI+DSB immediately before the ERET,
    after all explicit memory accesses. The ERET is currently in a separate alternative block, and
    alternatives cannot be nested. To account for this, the alternative block for ARM64_UNMAP_KERNEL_AT_EL0 is
    replaced with a single alternative branch to skip the KPTI logic, with the new shape of the logic being: |
    alternative_insn b .L_skip_tramp_exit_\@, nop, ARM64_UNMAP_KERNEL_AT_EL0 | [ ... KPTI exception return
    path ... ] | .L_skip_tramp_exit_\@: | | ldr lr, [sp, #S_LR] | add sp, sp, #PT_REGS_SIZE // restore sp | |
    alternative_if ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD | tlbi vale1, xzr | dsb nsh |
    alternative_else_nop_endif | eret The new structure means that the workaround is only applied when KPTI is
    not in use; this is fine as noted in the documented implications of the erratum: | Pagetable isolation
    between EL0 and higher level ELs prevents the | issue from occurring. ... and as per the workaround
    description quoted above, the workaround is only necessary If pagetable isolation is disabled.
    (CVE-2024-26670)

  - In the Linux kernel, the following vulnerability has been resolved: net: atlantic: Fix DMA mapping for PTP
    hwts ring Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes for PTP HWTS ring but then
    generic aq_ring_free() does not take this into account. Create and use a specific function to free HWTS
    ring to fix this issue. Trace: [ 215.351607] ------------[ cut here ]------------ [ 215.351612] DMA-API:
    atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device
    address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes] [ 215.351635] WARNING: CPU: 33
    PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360 ... [ 215.581176] Call Trace: [ 215.583632]
    <TASK> [ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df [ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df [
    215.594497] ? debug_dma_free_coherent+0x196/0x210 [ 215.599305] ? check_unmap+0xa6f/0x2360 [ 215.603147] ?
    __warn+0xca/0x1d0 [ 215.606391] ? check_unmap+0xa6f/0x2360 [ 215.610237] ? report_bug+0x1ef/0x370 [
    215.613921] ? handle_bug+0x3c/0x70 [ 215.617423] ? exc_invalid_op+0x14/0x50 [ 215.621269] ?
    asm_exc_invalid_op+0x16/0x20 [ 215.625480] ? check_unmap+0xa6f/0x2360 [ 215.629331] ?
    mark_lock.part.0+0xca/0xa40 [ 215.633445] debug_dma_free_coherent+0x196/0x210 [ 215.638079] ?
    __pfx_debug_dma_free_coherent+0x10/0x10 [ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0 [ 215.648060]
    dma_free_attrs+0x6d/0x130 [ 215.651834] aq_ring_free+0x193/0x290 [atlantic] [ 215.656487]
    aq_ptp_ring_free+0x67/0x110 [atlantic] ... [ 216.127540] ---[ end trace 6467e5964dd2640b ]--- [
    216.132160] DMA-API: Mapped at: [ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0 [ 216.132165]
    dma_alloc_attrs+0xf5/0x1b0 [ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic] [ 216.132193]
    aq_ptp_ring_alloc+0x1bb/0x540 [atlantic] [ 216.132213] aq_nic_init+0x4a1/0x760 [atlantic] (CVE-2024-26680)

  - In the Linux kernel, the following vulnerability has been resolved: netdevsim: avoid potential loop in
    nsim_dev_trap_report_work() Many syzbot reports include the following trace [1] If
    nsim_dev_trap_report_work() can not grab the mutex, it should rearm itself at least one jiffie later. [1]
    Sending NMI from CPU 1 to CPUs 0: NMI backtrace for cpu 0 CPU: 0 PID: 32383 Comm: kworker/0:2 Not tainted
    6.8.0-rc2-syzkaller-00031-g861c0981648f #0 Hardware name: Google Google Compute Engine/Google Compute
    Engine, BIOS Google 11/17/2023 Workqueue: events nsim_dev_trap_report_work RIP: 0010:bytes_is_nonzero
    mm/kasan/generic.c:89 [inline] RIP: 0010:memory_is_nonzero mm/kasan/generic.c:104 [inline] RIP:
    0010:memory_is_poisoned_n mm/kasan/generic.c:129 [inline] RIP: 0010:memory_is_poisoned
    mm/kasan/generic.c:161 [inline] RIP: 0010:check_region_inline mm/kasan/generic.c:180 [inline] RIP:
    0010:kasan_check_range+0x101/0x190 mm/kasan/generic.c:189 Code: 07 49 39 d1 75 0a 45 3a 11 b8 01 00 00 00
    7c 0b 44 89 c2 e8 21 ed ff ff 83 f0 01 5b 5d 41 5c c3 48 85 d2 74 4f 48 01 ea eb 09 <48> 83 c0 01 48 39 d0
    74 41 80 38 00 74 f2 eb b6 41 bc 08 00 00 00 RSP: 0018:ffffc90012dcf998 EFLAGS: 00000046 RAX:
    fffffbfff258af1e RBX: fffffbfff258af1f RCX: ffffffff8168eda3 RDX: fffffbfff258af1f RSI: 0000000000000004
    RDI: ffffffff92c578f0 RBP: fffffbfff258af1e R08: 0000000000000000 R09: fffffbfff258af1e R10:
    ffffffff92c578f3 R11: ffffffff8acbcbc0 R12: 0000000000000002 R13: ffff88806db38400 R14: 1ffff920025b9f42
    R15: ffffffff92c578e8 FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010
    DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00994e078 CR3: 000000002c250000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <NMI> </NMI> <TASK> instrument_atomic_read
    include/linux/instrumented.h:68 [inline] atomic_read include/linux/atomic/atomic-instrumented.h:32
    [inline] queued_spin_is_locked include/asm-generic/qspinlock.h:57 [inline] debug_spin_unlock
    kernel/locking/spinlock_debug.c:101 [inline] do_raw_spin_unlock+0x53/0x230
    kernel/locking/spinlock_debug.c:141 __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:150
    [inline] _raw_spin_unlock_irqrestore+0x22/0x70 kernel/locking/spinlock.c:194
    debug_object_activate+0x349/0x540 lib/debugobjects.c:726 debug_work_activate kernel/workqueue.c:578
    [inline] insert_work+0x30/0x230 kernel/workqueue.c:1650 __queue_work+0x62e/0x11d0 kernel/workqueue.c:1802
    __queue_delayed_work+0x1bf/0x270 kernel/workqueue.c:1953 queue_delayed_work_on+0x106/0x130
    kernel/workqueue.c:1989 queue_delayed_work include/linux/workqueue.h:563 [inline] schedule_delayed_work
    include/linux/workqueue.h:677 [inline] nsim_dev_trap_report_work+0x9c0/0xc80
    drivers/net/netdevsim/dev.c:842 process_one_work+0x886/0x15d0 kernel/workqueue.c:2633
    process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x8b9/0x1290
    kernel/workqueue.c:2787 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>
    (CVE-2024-26681)

  - In the Linux kernel, the following vulnerability has been resolved: net: stmmac: xgmac: fix handling of
    DPP safety error for DMA channels Commit 56e58d6c8a56 (net: stmmac: Implement Safety Features in XGMAC
    core) checks and reports safety errors, but leaves the Data Path Parity Errors for each channel in DMA
    unhandled at all, lead to a storm of interrupt. Fix it by checking and clearing the
    DMA_DPP_Interrupt_Status register. (CVE-2024-26684)

  - In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential bug in
    end_buffer_async_write According to a syzbot report, end_buffer_async_write(), which handles the
    completion of block device writes, may detect abnormal condition of the buffer async_write flag and cause
    a BUG_ON failure when using nilfs2. Nilfs2 itself does not use end_buffer_async_write(). But, the
    async_write flag is now used as a marker by commit 7f42ec394156 (nilfs2: fix issue with race condition of
    competition between segments for dirty blocks) as a means of resolving double list insertion of dirty
    blocks in nilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and the resulting crash. This
    modification is safe as long as it is used for file data and b-tree node blocks where the page caches are
    independent. However, it was irrelevant and redundant to also introduce async_write for segment summary
    and super root blocks that share buffers with the backing device. This led to the possibility that the
    BUG_ON check in end_buffer_async_write would fail as described above, if independent writebacks of the
    backing device occurred in parallel. The use of async_write for segment summary buffers has already been
    removed in a previous change. Fix this issue by removing the manipulation of the async_write flag for the
    remaining super root block buffer. (CVE-2024-26685)

  - In the Linux kernel, the following vulnerability has been resolved: ceph: prevent use-after-free in
    encode_cap_msg() In fs/ceph/caps.c, in encode_cap_msg(), use after free error was caught by KASAN at
    this line - 'ceph_buffer_get(arg->xattr_buf);'. This implies before the refcount could be increment here,
    it was freed. In same file, in handle_cap_grant() refcount is decremented by this line -
    'ceph_buffer_put(ci->i_xattrs.blob);'. It appears that a race occurred and resource was freed by the
    latter line before the former line could increment it. encode_cap_msg() is called by __send_cap() and
    __send_cap() is called by ceph_check_caps() after calling __prep_cap(). __prep_cap() is where
    arg->xattr_buf is assigned to ci->i_xattrs.blob. This is the spot where the refcount must be increased to
    prevent use after free error. (CVE-2024-26689)

  - In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Fix null pointer
    dereference in __sev_platform_shutdown_locked The SEV platform device can be shutdown with a null
    psp_master, e.g., using DEBUG_TEST_DRIVER_REMOVE. Found using KASAN: [ 137.148210] ccp 0000:23:00.1:
    enabling device (0000 -> 0002) [ 137.162647] ccp 0000:23:00.1: no command queues available [ 137.170598]
    ccp 0000:23:00.1: sev enabled [ 137.174645] ccp 0000:23:00.1: psp enabled [ 137.178890] general protection
    fault, probably for non-canonical address 0xdffffc000000001e: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN
    NOPTI [ 137.182693] KASAN: null-ptr-deref in range [0x00000000000000f0-0x00000000000000f7] [ 137.182693]
    CPU: 93 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc1+ #311 [ 137.182693] RIP:
    0010:__sev_platform_shutdown_locked+0x51/0x180 [ 137.182693] Code: 08 80 3c 08 00 0f 85 0e 01 00 00 48 8b
    1d 67 b6 01 08 48 b8 00 00 00 00 00 fc ff df 48 8d bb f0 00 00 00 48 89 f9 48 c1 e9 03 <80> 3c 01 00 0f 85
    fe 00 00 00 48 8b 9b f0 00 00 00 48 85 db 74 2c [ 137.182693] RSP: 0018:ffffc900000cf9b0 EFLAGS: 00010216
    [ 137.182693] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 000000000000001e [ 137.182693] RDX:
    0000000000000000 RSI: 0000000000000008 RDI: 00000000000000f0 [ 137.182693] RBP: ffffc900000cf9c8 R08:
    0000000000000000 R09: fffffbfff58f5a66 [ 137.182693] R10: ffffc900000cf9c8 R11: ffffffffac7ad32f R12:
    ffff8881e5052c28 [ 137.182693] R13: ffff8881e5052c28 R14: ffff8881758e43e8 R15: ffffffffac64abf8 [
    137.182693] FS: 0000000000000000(0000) GS:ffff889de7000000(0000) knlGS:0000000000000000 [ 137.182693] CS:
    0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 137.182693] CR2: 0000000000000000 CR3: 0000001cf7c7e000
    CR4: 0000000000350ef0 [ 137.182693] Call Trace: [ 137.182693] <TASK> [ 137.182693] ? show_regs+0x6c/0x80 [
    137.182693] ? __die_body+0x24/0x70 [ 137.182693] ? die_addr+0x4b/0x80 [ 137.182693] ?
    exc_general_protection+0x126/0x230 [ 137.182693] ? asm_exc_general_protection+0x2b/0x30 [ 137.182693] ?
    __sev_platform_shutdown_locked+0x51/0x180 [ 137.182693] sev_firmware_shutdown.isra.0+0x1e/0x80 [
    137.182693] sev_dev_destroy+0x49/0x100 [ 137.182693] psp_dev_destroy+0x47/0xb0 [ 137.182693]
    sp_destroy+0xbb/0x240 [ 137.182693] sp_pci_remove+0x45/0x60 [ 137.182693] pci_device_remove+0xaa/0x1d0 [
    137.182693] device_remove+0xc7/0x170 [ 137.182693] really_probe+0x374/0xbe0 [ 137.182693] ?
    srso_return_thunk+0x5/0x5f [ 137.182693] __driver_probe_device+0x199/0x460 [ 137.182693]
    driver_probe_device+0x4e/0xd0 [ 137.182693] __driver_attach+0x191/0x3d0 [ 137.182693] ?
    __pfx___driver_attach+0x10/0x10 [ 137.182693] bus_for_each_dev+0x100/0x190 [ 137.182693] ?
    __pfx_bus_for_each_dev+0x10/0x10 [ 137.182693] ? __kasan_check_read+0x15/0x20 [ 137.182693] ?
    srso_return_thunk+0x5/0x5f [ 137.182693] ? _raw_spin_unlock+0x27/0x50 [ 137.182693]
    driver_attach+0x41/0x60 [ 137.182693] bus_add_driver+0x2a8/0x580 [ 137.182693] driver_register+0x141/0x480
    [ 137.182693] __pci_register_driver+0x1d6/0x2a0 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] ?
    esrt_sysfs_init+0x1cd/0x5d0 [ 137.182693] ? __pfx_sp_mod_init+0x10/0x10 [ 137.182693]
    sp_pci_init+0x22/0x30 [ 137.182693] sp_mod_init+0x14/0x30 [ 137.182693] ? __pfx_sp_mod_init+0x10/0x10 [
    137.182693] do_one_initcall+0xd1/0x470 [ 137.182693] ? __pfx_do_one_initcall+0x10/0x10 [ 137.182693] ?
    parameq+0x80/0xf0 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] ? __kmalloc+0x3b0/0x4e0 [
    137.182693] ? kernel_init_freeable+0x92d/0x1050 [ 137.182693] ? kasan_populate_vmalloc_pte+0x171/0x190 [
    137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] kernel_init_freeable+0xa64/0x1050 [ 137.182693] ?
    __pfx_kernel_init+0x10/0x10 [ 137.182693] kernel_init+0x24/0x160 [ 137.182693] ? __switch_to_asm+0x3e/0x70
    [ 137.182693] ret_from_fork+0x40/0x80 [ 137.182693] ? __pfx_kernel_init+0x1 ---truncated---
    (CVE-2024-26695)

  - In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix hang in
    nilfs_lookup_dirty_data_buffers() Syzbot reported a hang issue in migrate_pages_batch() called by mbind()
    and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2. While migrate_pages_batch()
    locks a folio and waits for the writeback to complete, the log writer thread that should bring the
    writeback to completion picks up the folio being written back in nilfs_lookup_dirty_data_buffers() that it
    calls for subsequent log creation and was trying to lock the folio. Thus causing a deadlock. In the first
    place, it is unexpected that folios/pages in the middle of writeback will be updated and become dirty.
    Nilfs2 adds a checksum to verify the validity of the log being written and uses it for recovery at mount,
    so data changes during writeback are suppressed. Since this is broken, an unclean shutdown could
    potentially cause recovery to fail. Investigation revealed that the root cause is that the wait for
    writeback completion in nilfs_page_mkwrite() is conditional, and if the backing device does not require
    stable writes, data may be modified without waiting. Fix these issues by making nilfs_page_mkwrite() wait
    for writeback to finish regardless of the stable write requirement of the backing device. (CVE-2024-26696)

  - In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix data corruption in dsync
    block recovery for small block sizes The helper function nilfs_recovery_copy_block() of
    nilfs_recovery_dsync_blocks(), which recovers data from logs created by data sync writes during a mount
    after an unclean shutdown, incorrectly calculates the on-page offset when copying repair data to the
    file's page cache. In environments where the block size is smaller than the page size, this flaw can cause
    data corruption and leak uninitialized memory bytes during the recovery process. Fix these issues by
    correcting this byte offset calculation on the page. (CVE-2024-26697)

  - In the Linux kernel, the following vulnerability has been resolved: ext4: fix double-free of blocks due to
    wrong extents moved_len In ext4_move_extents(), moved_len is only updated when all moves are successfully
    executed, and only discards orig_inode and donor_inode preallocations when moved_len is not zero. When the
    loop fails to exit after successfully moving some extents, moved_len is not updated and remains at 0, so
    it does not discard the preallocations. If the moved extents overlap with the preallocated extents, the
    overlapped extents are freed twice in ext4_mb_release_inode_pa() and ext4_process_freed_data() (as
    described in commit 94d7c16cbbbd (ext4: Fix double-free of blocks with EXT4_IOC_MOVE_EXT)), and bb_free
    is incremented twice. Hence when trim is executed, a zero-division bug is triggered in
    mb_update_avg_fragment_size() because bb_free is not zero and bb_fragments is zero. Therefore, update
    move_len after each extent move to avoid the issue. (CVE-2024-26704)

  - In the Linux kernel, the following vulnerability has been resolved: HID: i2c-hid-of: fix NULL-deref on
    failed power up A while back the I2C HID implementation was split in an ACPI and OF part, but the new OF
    driver never initialises the client pointer which is dereferenced on power-up failures. (CVE-2024-26717)

  - In the Linux kernel, the following vulnerability has been resolved: dm-crypt, dm-verity: disable tasklets
    Tasklets have an inherent problem with memory corruption. The function tasklet_action_common calls
    tasklet_trylock, then it calls the tasklet callback and then it calls tasklet_unlock. If the tasklet
    callback frees the structure that contains the tasklet or if it calls some code that may free it,
    tasklet_unlock will write into free memory. The commits 8e14f610159d and d9a02e016aaf try to fix it for
    dm-crypt, but it is not a sufficient fix and the data corruption can still happen [1]. There is no fix for
    dm-verity and dm-verity will write into free memory with every tasklet-processed bio. There will be atomic
    workqueues implemented in the kernel 6.9 [2]. They will have better interface and they will not suffer
    from the memory corruption problem. But we need something that stops the memory corruption now and that
    can be backported to the stable kernels. So, I'm proposing this commit that disables tasklets in both dm-
    crypt and dm-verity. This commit doesn't remove the tasklet support, because the tasklet code will be
    reused when atomic workqueues will be implemented. [1]
    https://lore.kernel.org/all/[email protected]/T/ [2]
    https://lore.kernel.org/lkml/[email protected]/ (CVE-2024-26718)

  - In the Linux kernel, the following vulnerability has been resolved: ASoC: rt5645: Fix deadlock in
    rt5645_jack_detect_work() There is a path in rt5645_jack_detect_work(), where rt5645->jd_mutex is left
    locked forever. That may lead to deadlock when rt5645_jack_detect_work() is called for the second time.
    Found by Linux Verification Center (linuxtesting.org) with SVACE. (CVE-2024-26722)

  - In the Linux kernel, the following vulnerability has been resolved: btrfs: do not ASSERT() if the newly
    created subvolume already got read [BUG] There is a syzbot crash, triggered by the ASSERT() during
    subvolume creation: assertion failed: !anon_dev, in fs/btrfs/disk-io.c:1319 ------------[ cut here
    ]------------ kernel BUG at fs/btrfs/disk-io.c:1319! invalid opcode: 0000 [#1] PREEMPT SMP KASAN RIP:
    0010:btrfs_get_root_ref.part.0+0x9aa/0xa60 <TASK> btrfs_get_new_fs_root+0xd3/0xf0
    create_subvol+0xd02/0x1650 btrfs_mksubvol+0xe95/0x12b0 __btrfs_ioctl_snap_create+0x2f9/0x4f0
    btrfs_ioctl_snap_create+0x16b/0x200 btrfs_ioctl+0x35f0/0x5cf0 __x64_sys_ioctl+0x19d/0x210
    do_syscall_64+0x3f/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b ---[ end trace 0000000000000000 ]---
    [CAUSE] During create_subvol(), after inserting root item for the newly created subvolume, we would
    trigger btrfs_get_new_fs_root() to get the btrfs_root of that subvolume. The idea here is, we have
    preallocated an anonymous device number for the subvolume, thus we can assign it to the new subvolume. But
    there is really nothing preventing things like backref walk to read the new subvolume. If that happens
    before we call btrfs_get_new_fs_root(), the subvolume would be read out, with a new anonymous device
    number assigned already. In that case, we would trigger ASSERT(), as we really expect no one to read out
    that subvolume (which is not yet accessible from the fs). But things like backref walk is still possible
    to trigger the read on the subvolume. Thus our assumption on the ASSERT() is not correct in the first
    place. [FIX] Fix it by removing the ASSERT(), and just free the @anon_dev, reset it to 0, and continue. If
    the subvolume tree is read out by something else, it should have already get a new anon_dev assigned thus
    we only need to free the preallocated one. (CVE-2024-26727)

  - In the Linux kernel, the following vulnerability has been resolved: arp: Prevent overflow in
    arp_req_get(). syzkaller reported an overflown write in arp_req_get(). [0] When ioctl(SIOCGARP) is issued,
    arp_req_get() looks up an neighbour entry and copies neigh->ha to struct arpreq.arp_ha.sa_data. The arp_ha
    here is struct sockaddr, not struct sockaddr_storage, so the sa_data buffer is just 14 bytes. In the splat
    below, 2 bytes are overflown to the next int field, arp_flags. We initialise the field just after the
    memcpy(), so it's not a problem. However, when dev->addr_len is greater than 22 (e.g. MAX_ADDR_LEN),
    arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL) in arp_ioctl() before calling
    arp_req_get(). To avoid the overflow, let's limit the max length of memcpy(). Note that commit
    b5f0de6df6dc (net: dev: Convert sa_data to flexible array in struct sockaddr) just silenced syzkaller.
    [0]: memcpy: detected field-spanning write (size 16) of single field r->arp_ha.sa_data at
    net/ipv4/arp.c:1128 (size 14) WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0
    net/ipv4/arp.c:1128 Modules linked in: CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 RIP:
    0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48
    c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42
    de fb be 03 00 00 00 4c 89 e7 e8 a6 RSP: 0018:ffffc900050b7998 EFLAGS: 00010286 RAX: 0000000000000000 RBX:
    ffff88803a815000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001
    RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11:
    203a7970636d656d R12: ffff888039c54000 R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010
    FS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000
    CR0: 0000000080050033 CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0 DR0:
    0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0
    DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261
    inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981 sock_do_ioctl+0xdf/0x260 net/socket.c:1204
    sock_ioctl+0x3ef/0x650 net/socket.c:1321 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870
    [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856 do_syscall_x64
    arch/x86/entry/common.c:51 [inline] do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81
    entry_SYSCALL_64_after_hwframe+0x64/0xce RIP: 0033:0x7f172b262b8d Code: 66 2e 0f 1f 84 00 00 00 00 00 0f
    1f 00 f3 0f 1e fa 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:00007f172bf300b8 EFLAGS: 00000246
    ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d RDX:
    0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003 RBP: 00007f172b2d3493 R08: 0000000000000000
    R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13:
    000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000 </TASK> (CVE-2024-26733)

  - In the Linux kernel, the following vulnerability has been resolved: afs: Increase buffer size in
    afs_update_volume_status() The max length of volume->vid value is 20 characters. So increase idbuf[] size
    up to 24 to avoid overflow. Found by Linux Verification Center (linuxtesting.org) with SVACE. [DH:
    Actually, it's 20 + NUL, so increase it to 24 and use snprintf()] (CVE-2024-26736)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Fix racing between
    bpf_timer_cancel_and_free and bpf_timer_cancel The following race is possible between
    bpf_timer_cancel_and_free and bpf_timer_cancel. It will lead a UAF on the timer->timer.
    bpf_timer_cancel(); spin_lock(); t = timer->time; spin_unlock(); bpf_timer_cancel_and_free(); spin_lock();
    t = timer->timer; timer->timer = NULL; spin_unlock(); hrtimer_cancel(&t->timer); kfree(t); /* UAF on t */
    hrtimer_cancel(&t->timer); In bpf_timer_cancel_and_free, this patch frees the timer->timer after a rcu
    grace period. This requires a rcu_head addition to the struct bpf_hrtimer. Another kfree(t) happens in
    bpf_timer_init, this does not need a kfree_rcu because it is still under the spin_lock and timer->timer
    has not been visible by others yet. In bpf_timer_cancel, rcu_read_lock() is added because this helper can
    be used in a non rcu critical section context (e.g. from a sleepable bpf prog). Other timer->timer usages
    in helpers.c have been audited, bpf_timer_cancel() is the only place where timer->timer is used outside of
    the spin_lock. Another solution considered is to mark a t->flag in bpf_timer_cancel and clear it after
    hrtimer_cancel() is done. In bpf_timer_cancel_and_free, it busy waits for the flag to be cleared before
    kfree(t). This patch goes with a straight forward solution and frees timer->timer after a rcu grace
    period. (CVE-2024-26737)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/qedr: Fix qedr_create_user_qp
    error flow Avoid the following warning by making sure to free the allocated resources in case that
    qedr_init_user_queue() fail. -----------[ cut here ]----------- WARNING: CPU: 0 PID: 143192 at
    drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] Modules linked in:
    tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp
    scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache
    netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert
    iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1
    intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal
    drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif
    sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf
    fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore
    ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fuse drm xfs libcrc32c qede sd_mod ahci libahci t10_pi
    sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3 ghash_clmulni_intel megaraid_sas crc8 wmi
    [last unloaded: ib_srpt] CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted
    5.14.0-408.el9.x86_64 #1 Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022 RIP:
    0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] Code: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8
    67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00
    00 00 48 89 df e8 8e f5 ff ff e9 6d ff RSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286 RAX: ffff8f0889ee3f60
    RBX: ffff8f088c1a5200 RCX: 00000000802a0016 RDX: 00000000802a0017 RSI: 0000000000000001 RDI:
    ffff8f0880042600 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8f11fffd5000
    R11: 0000000000039000 R12: ffff8f0d5b36cd80 R13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15:
    0000000000000000 FS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000 CS: 0010 DS:
    0000 ES: 0000 CR0: 0000000080050033 CR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0 Call
    Trace: <TASK> ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ?
    ib_uverbs_close+0x1f/0xb0 [ib_uverbs] ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ? __warn+0x81/0x110
    ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ? report_bug+0x10a/0x140 ? handle_bug+0x3c/0x70 ?
    exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
    ib_uverbs_close+0x1f/0xb0 [ib_uverbs] __fput+0x94/0x250 task_work_run+0x5c/0x90 do_exit+0x270/0x4a0
    do_group_exit+0x2d/0x90 get_signal+0x87c/0x8c0 arch_do_signal_or_restart+0x25/0x100 ?
    ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs] exit_to_user_mode_loop+0x9c/0x130
    exit_to_user_mode_prepare+0xb6/0x100 syscall_exit_to_user_mode+0x12/0x40 do_syscall_64+0x69/0x90 ?
    syscall_exit_work+0x103/0x130 ? syscall_exit_to_user_mode+0x22/0x40 ? do_syscall_64+0x69/0x90 ?
    syscall_exit_work+0x103/0x130 ? syscall_exit_to_user_mode+0x22/0x40 ? do_syscall_64+0x69/0x90 ?
    do_syscall_64+0x69/0x90 ? common_interrupt+0x43/0xa0 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP:
    0033:0x1470abe3ec6b Code: Unable to access opcode bytes at RIP 0x1470abe3ec41. RSP: 002b:00007fff13ce9108
    EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX:
    00001470abe3ec6b RDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004 RBP: 00007fff13ce91e0
    R08: 0000558d9655da10 R09: 0000558d9655dd00 R10: 00007fff13ce95c0 R11: 0000000000000246 R12:
    00007fff13ce9358 R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470 </TASK> --[ end trace
    888a9b92e04c5c97 ]-- (CVE-2024-26743)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: Support specifying the
    srpt_service_guid parameter Make loading ib_srpt with this parameter set work. The current behavior is
    that setting that parameter while loading the ib_srpt kernel module triggers the following kernel crash:
    BUG: kernel NULL pointer dereference, address: 0000000000000000 Call Trace: <TASK> parse_one+0x18c/0x1d0
    parse_args+0xe1/0x230 load_module+0x8de/0xa60 init_module_from_file+0x8b/0xd0
    idempotent_init_module+0x181/0x240 __x64_sys_finit_module+0x5a/0xb0 do_syscall_64+0x5f/0xe0
    entry_SYSCALL_64_after_hwframe+0x6e/0x76 (CVE-2024-26744)

  - In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/iommu: IOMMU table is
    not initialized for kdump over SR-IOV When kdump kernel tries to copy dump data over SR-IOV, LPAR panics
    due to NULL pointer exception: Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG:
    Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc000000020847ad4
    Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
    Modules linked in: mlx5_core(+) vmx_crypto pseries_wdt papr_scm libnvdimm mlxfw tls psample sunrpc fuse
    overlay squashfs loop CPU: 12 PID: 315 Comm: systemd-udevd Not tainted 6.4.0-Test102+ #12 Hardware name:
    IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries NIP:
    c000000020847ad4 LR: c00000002083b2dc CTR: 00000000006cd18c REGS: c000000029162ca0 TRAP: 0300 Not tainted
    (6.4.0-Test102+) MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 48288244 XER: 00000008 CFAR:
    c00000002083b2d8 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 1 ... NIP _find_next_zero_bit+0x24/0x110
    LR bitmap_find_next_zero_area_off+0x5c/0xe0 Call Trace: dev_printk_emit+0x38/0x48 (unreliable)
    iommu_area_alloc+0xc4/0x180 iommu_range_alloc+0x1e8/0x580 iommu_alloc+0x60/0x130
    iommu_alloc_coherent+0x158/0x2b0 dma_iommu_alloc_coherent+0x3c/0x50 dma_alloc_attrs+0x170/0x1f0
    mlx5_cmd_init+0xc0/0x760 [mlx5_core] mlx5_function_setup+0xf0/0x510 [mlx5_core] mlx5_init_one+0x84/0x210
    [mlx5_core] probe_one+0x118/0x2c0 [mlx5_core] local_pci_probe+0x68/0x110 pci_call_probe+0x68/0x200
    pci_device_probe+0xbc/0x1a0 really_probe+0x104/0x540 __driver_probe_device+0xb4/0x230
    driver_probe_device+0x54/0x130 __driver_attach+0x158/0x2b0 bus_for_each_dev+0xa8/0x130
    driver_attach+0x34/0x50 bus_add_driver+0x16c/0x300 driver_register+0xa4/0x1b0
    __pci_register_driver+0x68/0x80 mlx5_init+0xb8/0x100 [mlx5_core] do_one_initcall+0x60/0x300
    do_init_module+0x7c/0x2b0 At the time of LPAR dump, before kexec hands over control to kdump kernel, DDWs
    (Dynamic DMA Windows) are scanned and added to the FDT. For the SR-IOV case, default DMA window ibm,dma-
    window is removed from the FDT and DDW added, for the device. Now, kexec hands over control to the kdump
    kernel. When the kdump kernel initializes, PCI busses are scanned and IOMMU group/tables created, in
    pci_dma_bus_setup_pSeriesLP(). For the SR-IOV case, there is no ibm,dma-window. The original commit:
    b1fc44eaa9ba, fixes the path where memory is pre-mapped (direct mapped) to the DDW. When TCEs are direct
    mapped, there is no need to initialize IOMMU tables. iommu_table_setparms_lpar() only considers ibm,dma-
    window property when initiallizing IOMMU table. In the scenario where TCEs are dynamically allocated for
    SR-IOV, newly created IOMMU table is not initialized. Later, when the device driver tries to enter TCEs
    for the SR-IOV device, NULL pointer execption is thrown from iommu_area_alloc(). The fix is to initialize
    the IOMMU table with DDW property stored in the FDT. There are 2 points to remember: 1. For the dedicated
    adapter, kdump kernel would encounter both default and DDW in FDT. In this case, DDW property is used to
    initialize the IOMMU table. 2. A DDW could be direct or dynamic mapped. kdump kernel would initialize
    IOMMU table and mark the existing DDW as dynamic. This works fine since, at the time of table
    initialization, iommu_table_clear() makes some space in the DDW, for some predefined number of TCEs which
    are needed for kdump to succeed. (CVE-2024-26745)

  - In the Linux kernel, the following vulnerability has been resolved: usb: roles: fix NULL pointer issue
    when put module's reference In current design, usb role class driver will get usb_role_switch parent's
    module reference after the user get usb_role_switch device and put the reference after the user put the
    usb_role_switch device. However, the parent device of usb_role_switch may be removed before the user put
    the usb_role_switch. If so, then, NULL pointer issue will be met when the user put the parent module's
    reference. This will save the module pointer in structure of usb_role_switch. Then, we don't need to find
    module by iterating long relations. (CVE-2024-26747)

  - In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: fixed memory use after
    free at cdns3_gadget_ep_disable() ... cdns3_gadget_ep_free_request(&priv_ep->endpoint,
    &priv_req->request); list_del_init(&priv_req->list); ... 'priv_req' actually free at
    cdns3_gadget_ep_free_request(). But list_del_init() use priv_req->list after it. [ 1542.642868][ T534]
    BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xd4 [ 1542.642868][ T534] [ 1542.653162][
    T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3): [ 1542.660311][ T534]
    __list_del_entry_valid+0x10/0xd4 [ 1542.665375][ T534] cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3] [
    1542.671571][ T534] usb_ep_disable+0x44/0xe4 [ 1542.675948][ T534] ffs_func_eps_disable+0x64/0xc8 [
    1542.680839][ T534] ffs_func_set_alt+0x74/0x368 [ 1542.685478][ T534] ffs_func_disable+0x18/0x28 Move
    list_del_init() before cdns3_gadget_ep_free_request() to resolve this problem. (CVE-2024-26749)

  - In the Linux kernel, the following vulnerability has been resolved: ARM: ep93xx: Add terminator to
    gpiod_lookup_table Without the terminator, if a con_id is passed to gpio_find() that does not exist in the
    lookup table the function will not stop looping correctly, and eventually cause an oops. (CVE-2024-26751)

  - In the Linux kernel, the following vulnerability has been resolved: gtp: fix use-after-free and null-ptr-
    deref in gtp_genl_dump_pdp() The gtp_net_ops pernet operations structure for the subsystem must be
    registered before registering the generic netlink family. Syzkaller hit 'general protection fault in
    gtp_genl_dump_pdp' bug: general protection fault, probably for non-canonical address 0xdffffc0000000002:
    0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
    CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1 Hardware name: QEMU Standard PC (Q35 +
    ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014 RIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp] Code: c6 89 c6 e8
    64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86 df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48
    c1 ea 03 <80> 3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74 RSP: 0018:ffff888014107220
    EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000002
    RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09:
    0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88800fcda588
    R14: 0000000000000001 R15: 0000000000000000 FS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000)
    knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1be4e766cf CR3:
    000000000c33e000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? show_regs+0x90/0xa0 ?
    die_addr+0x50/0xd0 ? exc_general_protection+0x148/0x220 ? asm_exc_general_protection+0x22/0x30 ?
    gtp_genl_dump_pdp+0x1be/0x800 [gtp] ? __alloc_skb+0x1dd/0x350 ? __pfx___alloc_skb+0x10/0x10
    genl_dumpit+0x11d/0x230 netlink_dump+0x5b9/0xce0 ? lockdep_hardirqs_on_prepare+0x253/0x430 ?
    __pfx_netlink_dump+0x10/0x10 ? kasan_save_track+0x10/0x40 ? __kasan_kmalloc+0x9b/0xa0 ?
    genl_start+0x675/0x970 __netlink_dump_start+0x6fc/0x9f0 genl_family_rcv_msg_dumpit+0x1bb/0x2d0 ?
    __pfx_genl_family_rcv_msg_dumpit+0x10/0x10 ? genl_op_from_small+0x2a/0x440 ? cap_capable+0x1d0/0x240 ?
    __pfx_genl_start+0x10/0x10 ? __pfx_genl_dumpit+0x10/0x10 ? __pfx_genl_done+0x10/0x10 ?
    security_capable+0x9d/0xe0 (CVE-2024-26754)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: target: pscsi: Fix bio_put() for
    error case As of commit 066ff571011d (block: turn bio_kmalloc into a simple kmalloc wrapper), a bio
    allocated by bio_kmalloc() must be freed by bio_uninit() and kfree(). That is not done properly for the
    error case, hitting WARN and NULL pointer dereference in bio_free(). (CVE-2024-26760)

  - In the Linux kernel, the following vulnerability has been resolved: dm-crypt: don't modify the data when
    using authenticated encryption It was said that authenticated encryption could produce invalid tag when
    the data that is being encrypted is modified [1]. So, fix this problem by copying the data into the clone
    bio first and then encrypt them inside the clone bio. This may reduce performance, but it is needed to
    prevent the user from corrupting the device by writing data with O_DIRECT and modifying them at the same
    time. [1] https://lore.kernel.org/all/[email protected]/T/ (CVE-2024-26763)

  - In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix sdma.h tx->num_descs off-
    by-one error Unfortunately the commit `fd8958efe877` introduced another error causing the `descs` array to
    overflow. This reults in further crashes easily reproducible by `sendmsg` system call. [ 1080.836473]
    general protection fault, probably for non-canonical address 0x400300015528b00a: 0000 [#1] PREEMPT SMP PTI
    [ 1080.869326] RIP: 0010:hfi1_ipoib_build_ib_tx_headers.constprop.0+0xe1/0x2b0 [hfi1] -- [ 1080.974535]
    Call Trace: [ 1080.976990] <TASK> [ 1081.021929] hfi1_ipoib_send_dma_common+0x7a/0x2e0 [hfi1] [
    1081.027364] hfi1_ipoib_send_dma_list+0x62/0x270 [hfi1] [ 1081.032633] hfi1_ipoib_send+0x112/0x300 [hfi1]
    [ 1081.042001] ipoib_start_xmit+0x2a9/0x2d0 [ib_ipoib] [ 1081.046978] dev_hard_start_xmit+0xc4/0x210 -- [
    1081.148347] __sys_sendmsg+0x59/0xa0 crash> ipoib_txreq 0xffff9cfeba229f00 struct ipoib_txreq { txreq = {
    list = { next = 0xffff9cfeba229f00, prev = 0xffff9cfeba229f00 }, descp = 0xffff9cfeba229f40, coalesce_buf
    = 0x0, wait = 0xffff9cfea4e69a48, complete = 0xffffffffc0fe0760 <hfi1_ipoib_sdma_complete>, packet_len =
    0x46d, tlen = 0x0, num_desc = 0x0, desc_limit = 0x6, next_descq_idx = 0x45c, coalesce_idx = 0x0, flags =
    0x0, descs = {{ qw = {0x8024000120dffb00, 0x4} # SDMA_DESC0_FIRST_DESC_FLAG (bit 63) }, { qw = {
    0x3800014231b108, 0x4} }, { qw = { 0x310000e4ee0fcf0, 0x8} }, { qw = { 0x3000012e9f8000, 0x8} }, { qw = {
    0x59000dfb9d0000, 0x8} }, { qw = { 0x78000e02e40000, 0x8} }} }, sdma_hdr = 0x400300015528b000, <<< invalid
    pointer in the tx request structure sdma_status = 0x0, SDMA_DESC0_LAST_DESC_FLAG (bit 62) complete = 0x0,
    priv = 0x0, txq = 0xffff9cfea4e69880, skb = 0xffff9d099809f400 } If an SDMA send consists of exactly 6
    descriptors and requires dword padding (in the 7th descriptor), the sdma_txreq descriptor array is not
    properly expanded and the packet will overflow into the container structure. This results in a panic when
    the send completion runs. The exact panic varies depending on what elements of the container structure get
    corrupted. The fix is to use the correct expression in _pad_sdma_tx_descs() to test the need to expand the
    descriptor array. With this patch the crashes are no longer reproducible and the machine is stable.
    (CVE-2024-26766)

  - In the Linux kernel, the following vulnerability has been resolved: nvmet-fc: avoid deadlock on delete
    association path When deleting an association the shutdown path is deadlocking because we try to flush the
    nvmet_wq nested. Avoid this by deadlock by deferring the put work into its own work item. (CVE-2024-26769)

  - In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: edma: Add some null
    pointer checks to the edma_probe devm_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-2024-26771)

  - In the Linux kernel, the following vulnerability has been resolved: spi: hisi-sfc-v3xx: Return IRQ_NONE if
    no interrupts were detected Return IRQ_NONE from the interrupt handler when no interrupt was detected.
    Because an empty interrupt will cause a null pointer error: Unable to handle kernel NULL pointer
    dereference at virtual address 0000000000000008 Call trace: complete+0x54/0x100
    hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx] __handle_irq_event_percpu+0x64/0x1e0
    handle_irq_event+0x7c/0x1cc (CVE-2024-26776)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix race condition on
    enabling fast-xmit fast-xmit must only be enabled after the sta has been uploaded to the driver, otherwise
    it could end up passing the not-yet-uploaded sta via drv_tx calls to the driver, leading to potential
    crashes because of uninitialized drv_priv data. Add a missing sta->uploaded check and re-check fast xmit
    after inserting a sta. (CVE-2024-26779)

  - In the Linux kernel, the following vulnerability has been resolved: mmc: mmci: stm32: fix DMA API
    overlapping mappings warning Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning: DMA-API:
    mmci-pl18x 48220000.mmc: cacheline tracking EEXIST, overlapping mappings aren't supported WARNING: CPU: 1
    PID: 51 at kernel/dma/debug.c:568 add_dma_entry+0x234/0x2f4 Modules linked in: CPU: 1 PID: 51 Comm:
    kworker/1:2 Not tainted 6.1.28 #1 Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT)
    Workqueue: events_freezable mmc_rescan Call trace: add_dma_entry+0x234/0x2f4 debug_dma_map_sg+0x198/0x350
    __dma_map_sg_attrs+0xa0/0x110 dma_map_sg_attrs+0x10/0x2c sdmmc_idma_prep_data+0x80/0xc0
    mmci_prep_data+0x38/0x84 mmci_start_data+0x108/0x2dc mmci_request+0xe4/0x190
    __mmc_start_request+0x68/0x140 mmc_start_request+0x94/0xc0 mmc_wait_for_req+0x70/0x100
    mmc_send_tuning+0x108/0x1ac sdmmc_execute_tuning+0x14c/0x210 mmc_execute_tuning+0x48/0xec
    mmc_sd_init_uhs_card.part.0+0x208/0x464 mmc_sd_init_card+0x318/0x89c mmc_attach_sd+0xe4/0x180
    mmc_rescan+0x244/0x320 DMA API debug brings to light leaking dma-mappings as dma_map_sg and dma_unmap_sg
    are not correctly balanced. If an error occurs in mmci_cmd_irq function, only mmci_dma_error function is
    called and as this API is not managed on stm32 variant, dma_unmap_sg is never called in this error path.
    (CVE-2024-26787)

  - In the Linux kernel, the following vulnerability has been resolved: dmaengine: fsl-qdma: fix SoC may hang
    on 16 byte unaligned read There is chip (ls1028a) errata: The SoC may hang on 16 byte unaligned read
    transactions by QDMA. Unaligned read transactions initiated by QDMA may stall in the NOC (Network On-
    Chip), causing a deadlock condition. Stalled transactions will trigger completion timeouts in PCIe
    controller. Workaround: Enable prefetch by setting the source descriptor prefetchable bit ( SD[PF] = 1 ).
    Implement this workaround. (CVE-2024-26790)

  - In the Linux kernel, the following vulnerability has been resolved: gtp: fix use-after-free and null-ptr-
    deref in gtp_newlink() The gtp_link_ops operations structure for the subsystem must be registered after
    registering the gtp_net_ops pernet operations structure. Syzkaller hit 'general protection fault in
    gtp_genl_dump_pdp' bug: [ 1010.702740] gtp: GTP module unloaded [ 1010.715877] general protection fault,
    probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI [ 1010.715888] KASAN:
    null-ptr-deref in range [0x0000000000000008-0x000000000000000f] [ 1010.715895] CPU: 1 PID: 128616 Comm:
    a.out Not tainted 6.8.0-rc6-std-def-alt1 #1 [ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9,
    2009), BIOS 1.16.0-alt1 04/01/2014 [ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.715915]
    Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00
    00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00 [
    1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203 [ 1010.715929] RAX: dffffc0000000000 RBX:
    ffff88800399c000 RCX: 0000000000000000 [ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI:
    0000000000000282 [ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000 [
    1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80 [ 1010.715947] R13:
    0000000000000000 R14: 0000000000000000 R15: 0000000000000400 [ 1010.715953] FS: 00007fd1509ab5c0(0000)
    GS:ffff88805b300000(0000) knlGS:0000000000000000 [ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 [ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0 [
    1010.715968] PKRU: 55555554 [ 1010.715972] Call Trace: [ 1010.715985] ? __die_body.cold+0x1a/0x1f [
    1010.715995] ? die_addr+0x43/0x70 [ 1010.716002] ? exc_general_protection+0x199/0x2f0 [ 1010.716016] ?
    asm_exc_general_protection+0x1e/0x30 [ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.716034] ?
    gtp_net_exit+0x150/0x150 [gtp] [ 1010.716042] __rtnl_newlink+0x1063/0x1700 [ 1010.716051] ?
    rtnl_setlink+0x3c0/0x3c0 [ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0 [ 1010.716070] ?
    kernel_text_address.part.0+0xbb/0xd0 [ 1010.716076] ? __kernel_text_address+0x56/0xa0 [ 1010.716084] ?
    unwind_get_return_address+0x5a/0xa0 [ 1010.716091] ? create_prof_cpu_mask+0x30/0x30 [ 1010.716098] ?
    arch_stack_walk+0x9e/0xf0 [ 1010.716106] ? stack_trace_save+0x91/0xd0 [ 1010.716113] ?
    stack_trace_consume_entry+0x170/0x170 [ 1010.716121] ? __lock_acquire+0x15c5/0x5380 [ 1010.716139] ?
    mark_held_locks+0x9e/0xe0 [ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0 [ 1010.716155] ?
    __rtnl_newlink+0x1700/0x1700 [ 1010.716160] rtnl_newlink+0x69/0xa0 [ 1010.716166]
    rtnetlink_rcv_msg+0x43b/0xc50 [ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0 [ 1010.716179] ?
    lock_acquire+0x1fe/0x560 [ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50 [ 1010.716196]
    netlink_rcv_skb+0x14d/0x440 [ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0 [ 1010.716208] ?
    netlink_ack+0xab0/0xab0 [ 1010.716213] ? netlink_deliver_tap+0x202/0xd50 [ 1010.716220] ?
    netlink_deliver_tap+0x218/0xd50 [ 1010.716226] ? __virt_addr_valid+0x30b/0x590 [ 1010.716233]
    netlink_unicast+0x54b/0x800 [ 1010.716240] ? netlink_attachskb+0x870/0x870 [ 1010.716248] ?
    __check_object_size+0x2de/0x3b0 [ 1010.716254] netlink_sendmsg+0x938/0xe40 [ 1010.716261] ?
    netlink_unicast+0x800/0x800 [ 1010.716269] ? __import_iovec+0x292/0x510 [ 1010.716276] ?
    netlink_unicast+0x800/0x800 [ 1010.716284] __sock_sendmsg+0x159/0x190 [ 1010.716290]
    ____sys_sendmsg+0x712/0x880 [ 1010.716297] ? sock_write_iter+0x3d0/0x3d0 [ 1010.716304] ?
    __ia32_sys_recvmmsg+0x270/0x270 [ 1010.716309] ? lock_acquire+0x1fe/0x560 [ 1010.716315] ?
    drain_array_locked+0x90/0x90 [ 1010.716324] ___sys_sendmsg+0xf8/0x170 [ 1010.716331] ?
    sendmsg_copy_msghdr+0x170/0x170 [ 1010.716337] ? lockdep_init_map ---truncated--- (CVE-2024-26793)

  - In the Linux kernel, the following vulnerability has been resolved: fbcon: always restore the old font
    data in fbcon_do_set_font() Commit a5a923038d70 (fbdev: fbcon: Properly revert changes when vc_resize()
    failed) started restoring old font data upon failure (of vc_resize()). But it performs so only for user
    fonts. It means that the system/internal fonts are not restored at all. So in result, the very first
    call to fbcon_do_set_font() performs no restore at all upon failing vc_resize(). This can be reproduced by
    Syzkaller to crash the system on the next invocation of font_get(). It's rather hard to hit the allocation
    failure in vc_resize() on the first font_set(), but not impossible. Esp. if fault injection is used to aid
    the execution/failure. It was demonstrated by Sirius: BUG: unable to handle page fault for address:
    fffffffffffffff8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD
    cb7b067 P4D cb7b067 PUD cb7d067 PMD 0 Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8007 Comm: poc Not
    tainted 6.7.0-g9d1694dc91ce #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1
    04/01/2014 RIP: 0010:fbcon_get_font+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286 Call Trace: <TASK>
    con_font_get drivers/tty/vt/vt.c:4558 [inline] con_font_op+0x1fc/0xf20 drivers/tty/vt/vt.c:4673 vt_k_ioctl
    drivers/tty/vt/vt_ioctl.c:474 [inline] vt_ioctl+0x632/0x2ec0 drivers/tty/vt/vt_ioctl.c:752
    tty_ioctl+0x6f8/0x1570 drivers/tty/tty_io.c:2803 vfs_ioctl fs/ioctl.c:51 [inline] ... So restore the font
    data in any case, not only for user fonts. Note the later 'if' is now protected by 'old_userfont' and not
    'old_data' as the latter is always set now. (And it is supposed to be non-NULL. Otherwise we would see the
    bug above again.) (CVE-2024-26798)

  - In the Linux kernel, the following vulnerability has been resolved: netlink: Fix kernel-infoleak-after-
    free in __skb_datagram_iter syzbot reported the following uninit-value access issue [1]:
    netlink_to_full_skb() creates a new `skb` and puts the `skb->data` passed as a 1st arg of
    netlink_to_full_skb() onto new `skb`. The data size is specified as `len` and passed to skb_put_data().
    This `len` is based on `skb->end` that is not data offset but buffer offset. The `skb->end` contains data
    and tailroom. Since the tailroom is not initialized when the new `skb` created, KMSAN detects
    uninitialized memory area when copying the data. This patch resolved this issue by correct the len from
    `skb->end` to `skb->len`, which is the actual data offset. BUG: KMSAN: kernel-infoleak-after-free in
    instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak-after-free
    in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf
    include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2
    include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance
    include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520
    lib/iov_iter.c:186 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter
    lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2
    include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline]
    _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 copy_to_iter include/linux/uio.h:197 [inline]
    simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532 __skb_datagram_iter+0x123/0xdc0
    net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg
    include/linux/skbuff.h:3960 [inline] packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482
    sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg net/socket.c:1066 [inline]
    sock_read_iter+0x467/0x580 net/socket.c:1136 call_read_iter include/linux/fs.h:2014 [inline] new_sync_read
    fs/read_write.c:389 [inline] vfs_read+0x8f6/0xe00 fs/read_write.c:470 ksys_read+0x20f/0x4c0
    fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [inline] __se_sys_read fs/read_write.c:621 [inline]
    __x64_sys_read+0x93/0xd0 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
    do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was
    stored to memory at: skb_put_data include/linux/skbuff.h:2622 [inline] netlink_to_full_skb
    net/netlink/af_netlink.c:181 [inline] __netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline]
    __netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325 netlink_deliver_tap
    net/netlink/af_netlink.c:338 [inline] netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline]
    netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x10f1/0x1250
    net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910
    sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline]
    ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg
    net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674
    [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52
    [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
    Uninit was created at: free_pages_prepare mm/page_alloc.c:1087 [inline] free_unref_page_prepare+0xb0/0xa40
    mm/page_alloc.c:2347 free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533 release_pages+0x23d3/0x2410
    mm/swap.c:1042 free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316 tlb_batch_pages ---truncated---
    (CVE-2024-26805)

  - In the Linux kernel, the following vulnerability has been resolved: spi: cadence-qspi: fix pointer
    reference in runtime PM hooks dev_get_drvdata() gets used to acquire the pointer to cqspi and the SPI
    controller. Neither embed the other; this lead to memory corruption. On a given platform (Mobileye EyeQ5)
    the memory corruption is hidden inside cqspi->f_pdata. Also, this uninitialised memory is used as a mutex
    (ctlr->bus_lock_mutex) by spi_controller_suspend(). (CVE-2024-26807)

  - In the Linux kernel, the following vulnerability has been resolved: afs: Fix endless loop in directory
    parsing If a directory has a block with only .__afsXXXX files in it (from uncompleted silly-rename),
    these .__afsXXXX files are skipped but without advancing the file position in the dir_context. This leads
    to afs_dir_iterate() repeating the block again and again. Fix this by making the code that skips the
    .__afsXXXX file also manually advance the file position. The symptoms are a soft lookup: watchdog: BUG:
    soft lockup - CPU#3 stuck for 52s! [check:5737] ... RIP: 0010:afs_dir_iterate_block+0x39/0x1fd ... ?
    watchdog_timer_fn+0x1a6/0x213 ... ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ?
    afs_dir_iterate_block+0x39/0x1fd afs_dir_iterate+0x10a/0x148 afs_readdir+0x30/0x4a iterate_dir+0x93/0xd3
    __do_sys_getdents64+0x6b/0xd4 This is almost certainly the actual fix for:
    https://bugzilla.kernel.org/show_bug.cgi?id=218496 (CVE-2024-26848)

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://bugzilla.suse.com/1177529");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1192145");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1194869");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1200465");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1205316");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1207948");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1209635");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1209657");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1212514");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1213456");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1214852");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1215221");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1215322");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1217339");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1217829");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1217959");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1217987");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1217988");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1217989");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1218321");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1218336");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1218479");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1218643");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1218777");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1219126");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1219169");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1219170");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1219264");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1219834");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220114");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220176");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220237");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220251");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220320");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220337");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220340");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220365");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220366");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220398");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220411");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220413");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220439");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220443");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220445");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220466");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220478");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220482");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220484");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220486");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220487");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220492");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220703");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220775");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220790");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220797");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220831");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220833");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220836");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220839");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220840");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220843");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220870");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220871");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220872");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220878");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220879");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220883");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220885");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220887");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220898");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220901");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220915");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220918");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220920");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220921");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220926");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220927");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220929");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220932");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220935");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220937");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220938");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220940");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220954");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220955");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220959");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220960");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220961");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220965");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220969");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220978");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220979");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220981");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220982");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220983");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220985");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220986");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220987");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220989");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220990");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221009");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221012");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221015");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221022");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221039");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221040");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221044");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221045");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221046");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221048");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221055");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221056");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221058");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221060");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221061");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221062");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221066");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221067");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221068");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221069");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221070");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221071");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221077");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221082");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221090");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221097");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221156");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221162");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221252");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221273");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221274");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221276");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221277");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221291");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221293");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221298");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221337");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221338");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221375");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221379");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221551");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221553");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221613");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221614");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221616");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221618");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221631");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221633");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221713");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221725");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221777");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221791");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221814");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221816");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221830");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221951");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222011");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222033");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222051");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222056");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222060");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222070");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222073");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222117");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222247");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222266");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222274");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222291");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222300");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222304");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222317");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222331");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222355");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222356");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222360");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222366");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222373");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222416");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222422");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222427");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222428");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222431");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222437");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222445");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222449");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222503");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222520");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222536");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222549");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222550");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222557");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222585");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222586");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222596");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222609");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222610");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222619");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222630");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222632");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222660");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222662");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222664");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222669");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222677");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222678");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222680");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222706");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222720");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222724");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222726");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222727");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222764");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222772");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222781");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222784");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222798");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222801");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222952");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223030");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223067");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223068");
  script_set_attribute(attribute:"see_also", value:"https://lists.suse.com/pipermail/sle-updates/2024-May/035140.html");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46925");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46926");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46927");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46929");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46930");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46931");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46933");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46936");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47082");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47087");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47091");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47093");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47094");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47095");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47096");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47097");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47098");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47099");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47100");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47101");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47102");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47104");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47105");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47107");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47108");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47181");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47182");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47183");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47185");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47189");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2022-4744");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2022-48626");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2022-48629");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2022-48630");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-0160");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-28746");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-35827");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-4881");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52447");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52450");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52453");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52454");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52469");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52470");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52474");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52476");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52477");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52481");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52484");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52486");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52488");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52492");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52493");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52494");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52497");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52500");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52501");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52502");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52503");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52504");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52507");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52508");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52509");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52510");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52511");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52513");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52515");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52517");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52518");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52519");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52520");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52523");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52524");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52525");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52528");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52529");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52532");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52561");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52563");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52564");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52566");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52567");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52569");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52574");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52575");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52576");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52582");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52583");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52587");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52591");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52594");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52595");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52597");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52598");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52599");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52600");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52601");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52602");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52603");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52604");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52605");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52606");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52607");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52608");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52612");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52615");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52617");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52619");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52621");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52623");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52627");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52628");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52632");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52636");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52637");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52639");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-6356");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-6535");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-6536");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-7042");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-7192");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-0841");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-2201");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-22099");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-23307");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-23850");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-25739");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-25742");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26599");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26600");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26602");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26612");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26614");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26620");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26627");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26629");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26642");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26645");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26646");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26651");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26654");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26659");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26660");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26664");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26667");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26670");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26680");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26681");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26684");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26685");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26689");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26695");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26696");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26697");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26704");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26717");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26718");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26722");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26727");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26733");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26736");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26737");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26743");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26744");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26745");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26747");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26749");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26751");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26754");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26760");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26763");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26766");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26769");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26771");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26776");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26779");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26787");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26790");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26793");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26798");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26805");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26807");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26848");
  script_set_attribute(attribute:"solution", value:
"Update the affected packages.");
  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:POC/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:P/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:"vuln_publication_date", value:"2022/01/26");
  script_set_attribute(attribute:"patch_publication_date", value:"2024/05/03");
  script_set_attribute(attribute:"plugin_publication_date", value:"2024/05/04");

  script_set_attribute(attribute:"plugin_type", value:"local");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-azure");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-azure-devel");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-devel-azure");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-source-azure");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-syms-azure");
  script_set_attribute(attribute:"cpe", value:"cpe:/o:novell:suse_linux:15");
  script_set_attribute(attribute:"generated_plugin", value:"current");
  script_end_attributes();

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

  script_copyright(english:"This script is Copyright (C) 2024 and is owned by Tenable, Inc. or an Affiliate thereof.");

  script_dependencies("ssh_get_info.nasl");
  script_require_keys("Host/local_checks_enabled", "Host/cpu", "Host/SuSE/release", "Host/SuSE/rpm-list");

  exit(0);
}


include('rpm.inc');

if (!get_kb_item('Host/local_checks_enabled')) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);
var os_release = get_kb_item("Host/SuSE/release");
if (isnull(os_release) || os_release !~ "^(SLED|SLES|SUSE)") audit(AUDIT_OS_NOT, "SUSE / openSUSE");
var os_ver = pregmatch(pattern: "^(SLE(S|D)(?:_SAP)?\d+|SUSE([\d.]+))", string:os_release);
if (isnull(os_ver)) audit(AUDIT_UNKNOWN_APP_VER, 'SUSE / openSUSE');
os_ver = os_ver[1];
if (! preg(pattern:"^(SLES15|SLES_SAP15|SUSE15\.5)$", string:os_ver)) audit(AUDIT_OS_NOT, 'SUSE SLES15 / SLES_SAP15 / openSUSE 15', 'SUSE / openSUSE (' + os_ver + ')');

if (!get_kb_item("Host/SuSE/rpm-list")) 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, 'SUSE / openSUSE (' + os_ver + ')', cpu);

var service_pack = get_kb_item("Host/SuSE/patchlevel");
if (isnull(service_pack)) service_pack = "0";
if (os_ver == "SLES15" && (! preg(pattern:"^(5)$", string:service_pack))) audit(AUDIT_OS_NOT, "SLES15 SP5", os_ver + " SP" + service_pack);
if (os_ver == "SLES_SAP15" && (! preg(pattern:"^(5)$", string:service_pack))) audit(AUDIT_OS_NOT, "SLES_SAP15 SP5", os_ver + " SP" + service_pack);

var pkgs = [
    {'reference':'kernel-azure-5.14.21-150500.33.48.1', 'sp':'5', 'cpu':'aarch64', 'release':'SLES_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
    {'reference':'kernel-azure-5.14.21-150500.33.48.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLES_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
    {'reference':'kernel-azure-devel-5.14.21-150500.33.48.1', 'sp':'5', 'cpu':'aarch64', 'release':'SLES_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
    {'reference':'kernel-azure-devel-5.14.21-150500.33.48.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLES_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
    {'reference':'kernel-devel-azure-5.14.21-150500.33.48.1', 'sp':'5', 'release':'SLES_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
    {'reference':'kernel-source-azure-5.14.21-150500.33.48.1', 'sp':'5', 'release':'SLES_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
    {'reference':'kernel-syms-azure-5.14.21-150500.33.48.1', 'sp':'5', 'cpu':'aarch64', 'release':'SLES_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
    {'reference':'kernel-syms-azure-5.14.21-150500.33.48.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLES_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
    {'reference':'kernel-azure-5.14.21-150500.33.48.1', 'sp':'5', 'cpu':'aarch64', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-public-cloud-release-15.5', 'sles-release-15.5']},
    {'reference':'kernel-azure-5.14.21-150500.33.48.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-public-cloud-release-15.5', 'sles-release-15.5']},
    {'reference':'kernel-azure-devel-5.14.21-150500.33.48.1', 'sp':'5', 'cpu':'aarch64', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-public-cloud-release-15.5', 'sles-release-15.5']},
    {'reference':'kernel-azure-devel-5.14.21-150500.33.48.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-public-cloud-release-15.5', 'sles-release-15.5']},
    {'reference':'kernel-devel-azure-5.14.21-150500.33.48.1', 'sp':'5', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-public-cloud-release-15.5', 'sles-release-15.5']},
    {'reference':'kernel-source-azure-5.14.21-150500.33.48.1', 'sp':'5', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-public-cloud-release-15.5', 'sles-release-15.5']},
    {'reference':'kernel-syms-azure-5.14.21-150500.33.48.1', 'sp':'5', 'cpu':'aarch64', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-public-cloud-release-15.5', 'sles-release-15.5']},
    {'reference':'kernel-syms-azure-5.14.21-150500.33.48.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-public-cloud-release-15.5', 'sles-release-15.5']},
    {'reference':'cluster-md-kmp-azure-5.14.21-150500.33.48.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
    {'reference':'cluster-md-kmp-azure-5.14.21-150500.33.48.1', 'cpu':'x86_64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
    {'reference':'dlm-kmp-azure-5.14.21-150500.33.48.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
    {'reference':'dlm-kmp-azure-5.14.21-150500.33.48.1', 'cpu':'x86_64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
    {'reference':'gfs2-kmp-azure-5.14.21-150500.33.48.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
    {'reference':'gfs2-kmp-azure-5.14.21-150500.33.48.1', 'cpu':'x86_64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
    {'reference':'kernel-azure-5.14.21-150500.33.48.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
    {'reference':'kernel-azure-5.14.21-150500.33.48.1', 'cpu':'x86_64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
    {'reference':'kernel-azure-devel-5.14.21-150500.33.48.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
    {'reference':'kernel-azure-devel-5.14.21-150500.33.48.1', 'cpu':'x86_64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
    {'reference':'kernel-azure-extra-5.14.21-150500.33.48.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
    {'reference':'kernel-azure-extra-5.14.21-150500.33.48.1', 'cpu':'x86_64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
    {'reference':'kernel-azure-livepatch-devel-5.14.21-150500.33.48.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
    {'reference':'kernel-azure-livepatch-devel-5.14.21-150500.33.48.1', 'cpu':'x86_64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
    {'reference':'kernel-azure-optional-5.14.21-150500.33.48.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
    {'reference':'kernel-azure-optional-5.14.21-150500.33.48.1', 'cpu':'x86_64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
    {'reference':'kernel-azure-vdso-5.14.21-150500.33.48.1', 'cpu':'x86_64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
    {'reference':'kernel-devel-azure-5.14.21-150500.33.48.1', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
    {'reference':'kernel-source-azure-5.14.21-150500.33.48.1', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
    {'reference':'kernel-syms-azure-5.14.21-150500.33.48.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
    {'reference':'kernel-syms-azure-5.14.21-150500.33.48.1', 'cpu':'x86_64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
    {'reference':'kselftests-kmp-azure-5.14.21-150500.33.48.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
    {'reference':'kselftests-kmp-azure-5.14.21-150500.33.48.1', 'cpu':'x86_64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
    {'reference':'ocfs2-kmp-azure-5.14.21-150500.33.48.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
    {'reference':'ocfs2-kmp-azure-5.14.21-150500.33.48.1', 'cpu':'x86_64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
    {'reference':'reiserfs-kmp-azure-5.14.21-150500.33.48.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
    {'reference':'reiserfs-kmp-azure-5.14.21-150500.33.48.1', 'cpu':'x86_64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']}
];

var ltss_caveat_required = FALSE;
var flag = 0;
foreach var package_array ( pkgs ) {
  var reference = NULL;
  var _release = NULL;
  var sp = NULL;
  var _cpu = NULL;
  var exists_check = NULL;
  var rpm_spec_vers_cmp = NULL;
  if (!empty_or_null(package_array['reference'])) reference = package_array['reference'];
  if (!empty_or_null(package_array['release'])) _release = package_array['release'];
  if (!empty_or_null(package_array['sp'])) sp = package_array['sp'];
  if (!empty_or_null(package_array['cpu'])) _cpu = package_array['cpu'];
  if (!empty_or_null(package_array['exists_check'])) exists_check = package_array['exists_check'];
  if (!empty_or_null(package_array['rpm_spec_vers_cmp'])) rpm_spec_vers_cmp = package_array['rpm_spec_vers_cmp'];
  if (reference && _release) {
    if (exists_check) {
      var check_flag = 0;
      foreach var check (exists_check) {
        if (!rpm_exists(release:_release, rpm:check)) continue;
        check_flag++;
      }
      if (!check_flag) continue;
    }
    if (rpm_check(release:_release, sp:sp, cpu:_cpu, reference:reference, rpm_spec_vers_cmp:rpm_spec_vers_cmp)) flag++;
  }
}

if (flag)
{
  security_report_v4(
      port       : 0,
      severity   : SECURITY_WARNING,
      extra      : rpm_report_get()
  );
  exit(0);
}
else
{
  var tested = pkg_tests_get();
  if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);
  else audit(AUDIT_PACKAGE_NOT_INSTALLED, 'cluster-md-kmp-azure / dlm-kmp-azure / gfs2-kmp-azure / etc');
}