SUSE SLES12 Security Update : kernel (SUSE-SU-2024:0976-1)

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

include('compat.inc');

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

  script_cve_id(
    "CVE-2019-25162",
    "CVE-2020-36777",
    "CVE-2020-36784",
    "CVE-2021-46906",
    "CVE-2021-46915",
    "CVE-2021-46921",
    "CVE-2021-46924",
    "CVE-2021-46929",
    "CVE-2021-46932",
    "CVE-2021-46953",
    "CVE-2021-46974",
    "CVE-2021-46991",
    "CVE-2021-46992",
    "CVE-2021-47013",
    "CVE-2021-47054",
    "CVE-2021-47076",
    "CVE-2021-47077",
    "CVE-2021-47078",
    "CVE-2022-48627",
    "CVE-2023-28746",
    "CVE-2023-35827",
    "CVE-2023-46343",
    "CVE-2023-52340",
    "CVE-2023-52429",
    "CVE-2023-52443",
    "CVE-2023-52445",
    "CVE-2023-52449",
    "CVE-2023-52451",
    "CVE-2023-52464",
    "CVE-2023-52475",
    "CVE-2023-52478",
    "CVE-2023-52482",
    "CVE-2023-52502",
    "CVE-2023-52530",
    "CVE-2023-52531",
    "CVE-2023-52532",
    "CVE-2023-52574",
    "CVE-2023-52597",
    "CVE-2023-52605",
    "CVE-2024-0607",
    "CVE-2024-1151",
    "CVE-2024-23849",
    "CVE-2024-23851",
    "CVE-2024-26585",
    "CVE-2024-26595",
    "CVE-2024-26600",
    "CVE-2024-26622"
  );
  script_xref(name:"SuSE", value:"SUSE-SU-2024:0976-1");

  script_name(english:"SUSE SLES12 Security Update : kernel (SUSE-SU-2024:0976-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 SLES12 host has packages installed that are affected by multiple vulnerabilities as referenced in
the SUSE-SU-2024:0976-1 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: i2c: Fix a potential use after free
    Free the adap structure only after we are done using it. This patch just moves the put_device() down a bit
    to avoid the use after free. [wsa: added comment to the code, added Fixes tag] (CVE-2019-25162)

  - In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: Fix memory leak in
    dvb_media_device_free() dvb_media_device_free() is leaking memory. Free `dvbdev->adapter->conn` before
    setting it to NULL, as documented in include/media/media-device.h: The media_entity instance itself must
    be freed explicitly by the driver if required. (CVE-2020-36777)

  - In the Linux kernel, the following vulnerability has been resolved: i2c: cadence: fix reference leak when
    pm_runtime_get_sync fails The PM reference count is not expected to be incremented on return in functions
    cdns_i2c_master_xfer and cdns_reg_slave. However, pm_runtime_get_sync will increment pm usage counter even
    failed. Forgetting to putting operation will result in a reference leak here. Replace it with
    pm_runtime_resume_and_get to keep usage counter balanced. (CVE-2020-36784)

  - In the Linux kernel, the following vulnerability has been resolved: HID: usbhid: fix info leak in
    hid_submit_ctrl In hid_submit_ctrl(), the way of calculating the report length doesn't take into account
    that report->size can be zero. When running the syzkaller reproducer, a report of size 0 causes
    hid_submit_ctrl) to calculate transfer_buffer_length as 16384. When this urb is passed to the usb core
    layer, KMSAN reports an info leak of 16384 bytes. To fix this, first modify hid_report_len() to account
    for the zero report size case by using DIV_ROUND_UP for the division. Then, call it from
    hid_submit_ctrl(). (CVE-2021-46906)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_limit: avoid possible
    divide error in nft_limit_init div_u64() divides u64 by u32. nft_limit_init() wants to divide u64 by u64,
    use the appropriate math function (div64_u64) divide error: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8390
    Comm: syz-executor188 Not tainted 5.12.0-rc4-syzkaller #0 Hardware name: Google Google Compute
    Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:div_u64_rem include/linux/math64.h:28
    [inline] RIP: 0010:div_u64 include/linux/math64.h:127 [inline] RIP: 0010:nft_limit_init+0x2a2/0x5e0
    net/netfilter/nft_limit.c:85 Code: ef 4c 01 eb 41 0f 92 c7 48 89 de e8 38 a5 22 fa 4d 85 ff 0f 85 97 02 00
    00 e8 ea 9e 22 fa 4c 0f af f3 45 89 ed 31 d2 4c 89 f0 <49> f7 f5 49 89 c6 e8 d3 9e 22 fa 48 8d 7d 48 48 b8
    00 00 00 00 00 RSP: 0018:ffffc90009447198 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000200000000000
    RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff875152e6 RDI: 0000000000000003 RBP:
    ffff888020f80908 R08: 0000200000000000 R09: 0000000000000000 R10: ffffffff875152d8 R11: 0000000000000000
    R12: ffffc90009447270 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS:
    000000000097a300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 00000000200001c4 CR3: 0000000026a52000 CR4: 00000000001506e0 DR0: 0000000000000000
    DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400 Call Trace: nf_tables_newexpr net/netfilter/nf_tables_api.c:2675 [inline]
    nft_expr_init+0x145/0x2d0 net/netfilter/nf_tables_api.c:2713 nft_set_elem_expr_alloc+0x27/0x280
    net/netfilter/nf_tables_api.c:5160 nf_tables_newset+0x1997/0x3150 net/netfilter/nf_tables_api.c:4321
    nfnetlink_rcv_batch+0x85a/0x21b0 net/netfilter/nfnetlink.c:456 nfnetlink_rcv_skb_batch
    net/netfilter/nfnetlink.c:580 [inline] nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:598
    netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0
    net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec
    net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810
    net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433
    do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae
    (CVE-2021-46915)

  - In the Linux kernel, the following vulnerability has been resolved: locking/qrwlock: Fix ordering in
    queued_write_lock_slowpath() While this code is executed with the wait_lock held, a reader can acquire the
    lock without holding wait_lock. The writer side loops checking the value with the
    atomic_cond_read_acquire(), but only truly acquires the lock when the compare-and-exchange is completed
    successfully which isn't ordered. This exposes the window between the acquire and the cmpxchg to an A-B-A
    problem which allows reads following the lock acquisition to observe values speculatively before the write
    lock is truly acquired. We've seen a problem in epoll where the reader does a xchg while holding the read
    lock, but the writer can see a value change out from under it. Writer | Reader
    -------------------------------------------------------------------------------- ep_scan_ready_list() | |-
    write_lock_irq() | |- queued_write_lock_slowpath() | |- atomic_cond_read_acquire() | |
    read_lock_irqsave(&ep->lock, flags); --> (observes value before unlock) | chain_epi_lockless() | |
    epi->next = xchg(&ep->ovflist, epi); | | read_unlock_irqrestore(&ep->lock, flags); | | |
    atomic_cmpxchg_relaxed() | |-- READ_ONCE(ep->ovflist); | A core can order the read of the ovflist ahead of
    the atomic_cmpxchg_relaxed(). Switching the cmpxchg to use acquire semantics addresses this issue at which
    point the atomic_cond_read can be switched to use relaxed semantics. [peterz: use try_cmpxchg()]
    (CVE-2021-46921)

  - In the Linux kernel, the following vulnerability has been resolved: NFC: st21nfca: Fix memory leak in
    device probe and remove 'phy->pending_skb' is alloced when device probe, but forgot to free in the error
    handling path and remove path, this cause memory leak as follows: unreferenced object 0xffff88800bc06800
    (size 512): comm 8, pid 11775, jiffies 4295159829 (age 9.032s) hex dump (first 32 bytes): 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    ................ backtrace: [<00000000d66c09ce>] __kmalloc_node_track_caller+0x1ed/0x450
    [<00000000c93382b3>] kmalloc_reserve+0x37/0xd0 [<000000005fea522c>] __alloc_skb+0x124/0x380
    [<0000000019f29f9a>] st21nfca_hci_i2c_probe+0x170/0x8f2 Fix it by freeing 'pending_skb' in error and
    remove. (CVE-2021-46924)

  - 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: Input: appletouch - initialize work
    before device registration Syzbot has reported warning in __flush_work(). This warning is caused by
    work->func == NULL, which means missing work initialization. This may happen, since input_dev->close()
    calls cancel_work_sync(&dev->work), but dev->work initalization happens _after_ input_register_device()
    call. So this patch moves dev->work initialization before registering input device (CVE-2021-46932)

  - In the Linux kernel, the following vulnerability has been resolved: ACPI: GTDT: Don't corrupt interrupt
    mappings on watchdow probe failure When failing the driver probe because of invalid firmware properties,
    the GTDT driver unmaps the interrupt that it mapped earlier. However, it never checks whether the mapping
    of the interrupt actially succeeded. Even more, should the firmware report an illegal interrupt number
    that overlaps with the GIC SGI range, this can result in an IPI being unmapped, and subsequent fireworks
    (as reported by Dann Frazier). Rework the driver to have a slightly saner behaviour and actually check
    whether the interrupt has been mapped before unmapping things. (CVE-2021-46953)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Fix masking negation logic upon
    negative dst register The negation logic for the case where the off_reg is sitting in the dst register is
    not correct given then we cannot just invert the add to a sub or vice versa. As a fix, perform the final
    bitwise and-op unconditionally into AX from the off_reg, then move the pointer from the src to dst and
    finally use AX as the source for the original pointer arithmetic operation such that the inversion yields
    a correct result. The single non-AX mov in between is possible given constant blinding is retaining it as
    it's not an immediate based operation. (CVE-2021-46974)

  - In the Linux kernel, the following vulnerability has been resolved: i40e: Fix use-after-free in
    i40e_client_subtask() Currently the call to i40e_client_del_instance frees the object pf->cinst, however
    pf->cinst->lan_info is being accessed after the free. Fix this by adding the missing return. Addresses-
    Coverity: (Read from pointer after free) (CVE-2021-46991)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nftables: avoid overflows
    in nft_hash_buckets() Number of buckets being stored in 32bit variables, we have to ensure that no
    overflows occur in nft_hash_buckets() syzbot injected a size == 0x40000000 and reported: UBSAN: shift-out-
    of-bounds in ./include/linux/log2.h:57:13 shift exponent 64 is too large for 64-bit type 'long unsigned
    int' CPU: 1 PID: 29539 Comm: syz-executor.4 Not tainted 5.12.0-rc7-syzkaller #0 Hardware name: Google
    Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack
    lib/dump_stack.c:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 ubsan_epilogue+0xb/0x5a
    lib/ubsan.c:148 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327 __roundup_pow_of_two
    include/linux/log2.h:57 [inline] nft_hash_buckets net/netfilter/nft_set_hash.c:411 [inline]
    nft_hash_estimate.cold+0x19/0x1e net/netfilter/nft_set_hash.c:652 nft_select_set_ops
    net/netfilter/nf_tables_api.c:3586 [inline] nf_tables_newset+0xe62/0x3110
    net/netfilter/nf_tables_api.c:4322 nfnetlink_rcv_batch+0xa09/0x24b0 net/netfilter/nfnetlink.c:488
    nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:612 [inline] nfnetlink_rcv+0x3af/0x420
    net/netfilter/nfnetlink.c:630 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline]
    netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90
    net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120
    net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404
    __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
    (CVE-2021-46992)

  - In the Linux kernel, the following vulnerability has been resolved: net:emac/emac-mac: Fix a use after
    free in emac_mac_tx_buf_send In emac_mac_tx_buf_send, it calls emac_tx_fill_tpd(..,skb,..). If some error
    happens in emac_tx_fill_tpd(), the skb will be freed via dev_kfree_skb(skb) in error branch of
    emac_tx_fill_tpd(). But the freed skb is still used via skb->len by netdev_sent_queue(,skb->len). As i
    observed that emac_tx_fill_tpd() haven't modified the value of skb->len, thus my patch assigns skb->len to
    'len' before the possible free and use 'len' instead of skb->len later. (CVE-2021-47013)

  - In the Linux kernel, the following vulnerability has been resolved: bus: qcom: Put child node before
    return Put child node before return to fix potential reference count leak. Generally, the reference count
    of child is incremented and decremented automatically in the macro for_each_available_child_of_node() and
    should be decremented manually if the loop is broken in loop body. (CVE-2021-47054)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Return CQE error if invalid
    lkey was supplied RXE is missing update of WQE status in LOCAL_WRITE failures. This caused the following
    kernel panic if someone sent an atomic operation with an explicitly wrong lkey. [leonro@vm ~]$ mkt test
    test_atomic_invalid_lkey (tests.test_atomic.AtomicTest) ... WARNING: CPU: 5 PID: 263 at
    drivers/infiniband/sw/rxe/rxe_comp.c:740 rxe_completer+0x1a6d/0x2e30 [rdma_rxe] Modules linked in:
    crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel rdma_ucm rdma_cm ib_umad ib_ipoib iw_cm ib_cm mlx5_ib
    ib_uverbs ib_core mlx5_core ptp pps_core CPU: 5 PID: 263 Comm: python3 Not tainted 5.13.0-rc1+ #2936
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org
    04/01/2014 RIP: 0010:rxe_completer+0x1a6d/0x2e30 [rdma_rxe] Code: 03 0f 8e 65 0e 00 00 3b 93 10 06 00 00
    0f 84 82 0a 00 00 4c 89 ff 4c 89 44 24 38 e8 2d 74 a9 e1 4c 8b 44 24 38 e9 1c f5 ff ff <0f> 0b e9 0c e8 ff
    ff b8 05 00 00 00 41 bf 05 00 00 00 e9 ab e7 ff RSP: 0018:ffff8880158af090 EFLAGS: 00010246 RAX:
    0000000000000000 RBX: ffff888016a78000 RCX: ffffffffa0cf1652 RDX: 1ffff9200004b442 RSI: 0000000000000004
    RDI: ffffc9000025a210 RBP: dffffc0000000000 R08: 00000000ffffffea R09: ffff88801617740b R10:
    ffffed1002c2ee81 R11: 0000000000000007 R12: ffff88800f3b63e8 R13: ffff888016a78008 R14: ffffc9000025a180
    R15: 000000000000000c FS: 00007f88b622a740(0000) GS:ffff88806d540000(0000) knlGS:0000000000000000 CS: 0010
    DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f88b5a1fa10 CR3: 000000000d848004 CR4: 0000000000370ea0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000400 Call Trace: rxe_do_task+0x130/0x230 [rdma_rxe] rxe_rcv+0xb11/0x1df0
    [rdma_rxe] rxe_loopback+0x157/0x1e0 [rdma_rxe] rxe_responder+0x5532/0x7620 [rdma_rxe]
    rxe_do_task+0x130/0x230 [rdma_rxe] rxe_rcv+0x9c8/0x1df0 [rdma_rxe] rxe_loopback+0x157/0x1e0 [rdma_rxe]
    rxe_requester+0x1efd/0x58c0 [rdma_rxe] rxe_do_task+0x130/0x230 [rdma_rxe] rxe_post_send+0x998/0x1860
    [rdma_rxe] ib_uverbs_post_send+0xd5f/0x1220 [ib_uverbs] ib_uverbs_write+0x847/0xc80 [ib_uverbs]
    vfs_write+0x1c5/0x840 ksys_write+0x176/0x1d0 do_syscall_64+0x3f/0x80
    entry_SYSCALL_64_after_hwframe+0x44/0xae (CVE-2021-47076)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Add pointer checks in
    qedf_update_link_speed() The following trace was observed: [ 14.042059] Call Trace: [ 14.042061] <IRQ> [
    14.042068] qedf_link_update+0x144/0x1f0 [qedf] [ 14.042117] qed_link_update+0x5c/0x80 [qed] [ 14.042135]
    qed_mcp_handle_link_change+0x2d2/0x410 [qed] [ 14.042155] ? qed_set_ptt+0x70/0x80 [qed] [ 14.042170] ?
    qed_set_ptt+0x70/0x80 [qed] [ 14.042186] ? qed_rd+0x13/0x40 [qed] [ 14.042205]
    qed_mcp_handle_events+0x437/0x690 [qed] [ 14.042221] ? qed_set_ptt+0x70/0x80 [qed] [ 14.042239]
    qed_int_sp_dpc+0x3a6/0x3e0 [qed] [ 14.042245] tasklet_action_common.isra.14+0x5a/0x100 [ 14.042250]
    __do_softirq+0xe4/0x2f8 [ 14.042253] irq_exit+0xf7/0x100 [ 14.042255] do_IRQ+0x7f/0xd0 [ 14.042257]
    common_interrupt+0xf/0xf [ 14.042259] </IRQ> API qedf_link_update() is getting called from QED but by that
    time shost_data is not initialised. This results in a NULL pointer dereference when we try to dereference
    shost_data while updating supported_speeds. Add a NULL pointer check before dereferencing shost_data.
    (CVE-2021-47077)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Clear all QP fields if
    creation failed rxe_qp_do_cleanup() relies on valid pointer values in QP for the properly created ones,
    but in case rxe_qp_from_init() failed it was filled with garbage and caused tot the following error.
    refcount_t: underflow; use-after-free. WARNING: CPU: 1 PID: 12560 at lib/refcount.c:28
    refcount_warn_saturate+0x1d1/0x1e0 lib/refcount.c:28 Modules linked in: CPU: 1 PID: 12560 Comm: syz-
    executor.4 Not tainted 5.12.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute
    Engine, BIOS Google 01/01/2011 RIP: 0010:refcount_warn_saturate+0x1d1/0x1e0 lib/refcount.c:28 Code: e9 db
    fe ff ff 48 89 df e8 2c c2 ea fd e9 8a fe ff ff e8 72 6a a7 fd 48 c7 c7 e0 b2 c1 89 c6 05 dc 3a e6 09 01
    e8 ee 74 fb 04 <0f> 0b e9 af fe ff ff 0f 1f 84 00 00 00 00 00 41 56 41 55 41 54 55 RSP:
    0018:ffffc900097ceba8 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
    RDX: 0000000000040000 RSI: ffffffff815bb075 RDI: fffff520012f9d67 RBP: 0000000000000003 R08:
    0000000000000000 R09: 0000000000000000 R10: ffffffff815b4eae R11: 0000000000000000 R12: ffff8880322a4800
    R13: ffff8880322a4940 R14: ffff888033044e00 R15: 0000000000000000 FS: 00007f6eb2be3700(0000)
    GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    00007fdbe5d41000 CR3: 000000001d181000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000
    DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:
    __refcount_sub_and_test include/linux/refcount.h:283 [inline] __refcount_dec_and_test
    include/linux/refcount.h:315 [inline] refcount_dec_and_test include/linux/refcount.h:333 [inline] kref_put
    include/linux/kref.h:64 [inline] rxe_qp_do_cleanup+0x96f/0xaf0 drivers/infiniband/sw/rxe/rxe_qp.c:805
    execute_in_process_context+0x37/0x150 kernel/workqueue.c:3327 rxe_elem_release+0x9f/0x180
    drivers/infiniband/sw/rxe/rxe_pool.c:391 kref_put include/linux/kref.h:65 [inline]
    rxe_create_qp+0x2cd/0x310 drivers/infiniband/sw/rxe/rxe_verbs.c:425 _ib_create_qp
    drivers/infiniband/core/core_priv.h:331 [inline] ib_create_named_qp+0x2ad/0x1370
    drivers/infiniband/core/verbs.c:1231 ib_create_qp include/rdma/ib_verbs.h:3644 [inline]
    create_mad_qp+0x177/0x2d0 drivers/infiniband/core/mad.c:2920 ib_mad_port_open
    drivers/infiniband/core/mad.c:3001 [inline] ib_mad_init_device+0xd6f/0x1400
    drivers/infiniband/core/mad.c:3092 add_client_context+0x405/0x5e0 drivers/infiniband/core/device.c:717
    enable_device_and_get+0x1cd/0x3b0 drivers/infiniband/core/device.c:1331 ib_register_device
    drivers/infiniband/core/device.c:1413 [inline] ib_register_device+0x7c7/0xa50
    drivers/infiniband/core/device.c:1365 rxe_register_device+0x3d5/0x4a0
    drivers/infiniband/sw/rxe/rxe_verbs.c:1147 rxe_add+0x12fe/0x16d0 drivers/infiniband/sw/rxe/rxe.c:247
    rxe_net_add+0x8c/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:503 rxe_newlink
    drivers/infiniband/sw/rxe/rxe.c:269 [inline] rxe_newlink+0xb7/0xe0 drivers/infiniband/sw/rxe/rxe.c:250
    nldev_newlink+0x30e/0x550 drivers/infiniband/core/nldev.c:1555 rdma_nl_rcv_msg+0x36d/0x690
    drivers/infiniband/core/netlink.c:195 rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline]
    rdma_nl_rcv+0x2ee/0x430 drivers/infiniband/core/netlink.c:259 netlink_unicast_kernel
    net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338
    netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline]
    sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350
    ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433
    do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0 ---truncated---
    (CVE-2021-47078)

  - In the Linux kernel, the following vulnerability has been resolved: vt: fix memory overlapping when
    deleting chars in the buffer A memory overlapping copy occurs when deleting a long line. This memory
    overlapping copy can cause data corruption when scr_memcpyw is optimized to memcpy because memcpy does not
    ensure its behavior if the destination buffer overlaps with the source buffer. The line buffer is not
    always broken, because the memcpy utilizes the hardware acceleration, whose result is not deterministic.
    Fix this problem by using replacing the scr_memcpyw with scr_memmovew. (CVE-2022-48627)

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

  - In the Linux kernel before 6.5.9, there is a NULL pointer dereference in send_acknowledge in
    net/nfc/nci/spi.c. (CVE-2023-46343)

  - When a router encounters an IPv6 packet too big to transmit to the next-hop, it returns an ICMP6 Packet
    Too Big (PTB) message to the sender. The sender caches this updated Maximum Transmission Unit (MTU) so it
    knows not to exceed this value when subsequently routing to the same host. (CVE-2023-52340)

  - dm_table_create in drivers/md/dm-table.c in the Linux kernel through 6.7.4 can attempt to (in
    alloc_targets) allocate more than INT_MAX bytes, and crash, because of a missing check for struct
    dm_ioctl.target_count. (CVE-2023-52429)

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

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

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

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

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

  - In the Linux kernel, the following vulnerability has been resolved: Input: powermate - fix use-after-free
    in powermate_config_complete syzbot has found a use-after-free bug [1] in the powermate driver. This
    happens when the device is disconnected, which leads to a memory free from the powermate_device struct.
    When an asynchronous control message completes after the kfree and its callback is invoked, the lock does
    not exist anymore and hence the bug. Use usb_kill_urb() on pm->config to cancel any in-progress requests
    upon device disconnection. [1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e
    (CVE-2023-52475)

  - In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Fix kernel crash
    on receiver USB disconnect hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races
    when it races with itself. hidpp_connect_event() primarily runs from a workqueue but it also runs on
    probe() and if a device-connected packet is received by the hw when the thread running
    hidpp_connect_event() from probe() is waiting on the hw, then a second thread running
    hidpp_connect_event() will be started from the workqueue. This opens the following races (note the below
    code is simplified): 1. Retrieving + printing the protocol (harmless race): if (!hidpp->protocol_major) {
    hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; } We can actually see
    this race hit in the dmesg in the abrt output attached to rhbz#2227968: [ 3064.624215] logitech-hidpp-
    device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device
    0003:046D:4071.0049: HID++ 4.5 device connected. Testing with extra logging added has shown that after
    this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the
    other TOCTOU cases managing to hit all of them: 2. Updating the name to the HIDPP name (harmless race): if
    (hidpp->name == hdev->name) { ... hidpp->name = new_name; } 3. Initializing the power_supply class for the
    battery (problematic!): hidpp_initialize_battery() { if (hidpp->battery.ps) return 0; probe_battery(); /*
    Blocks, threads take turns executing this */ hidpp->battery.desc.properties = devm_kmemdup(dev,
    hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps =
    devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); } 4. Creating delayed
    input_device (potentially problematic): if (hidpp->delayed_input) return; hidpp->delayed_input =
    hidpp_allocate_input(hdev); The really big problem here is 3. Hitting the race leads to the following
    sequence: hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);
    hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); ...
    hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);
    hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); So now we
    have registered 2 power supplies for the same battery, which looks a bit weird from userspace's pov but
    this is not even the really big problem. Notice how: 1. This is all devm-maganaged 2. The
    hidpp->battery.desc struct is shared between the 2 power supplies 3. hidpp->battery.desc.properties points
    to the result from the second devm_kmemdup() This causes a use after free scenario on USB disconnect of
    the receiver: 1. The last registered power supply class device gets unregistered 2. The memory from the
    last devm_kmemdup() call gets freed, hidpp->battery.desc.properties now points to freed memory 3. The
    first registered power supply class device gets unregistered, this involves sending a remove uevent to
    userspace which invokes power_supply_uevent() to fill the uevent data 4. power_supply_uevent() uses
    hidpp->battery.desc.properties which now points to freed memory leading to backtraces like this one: Sep
    22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08 ... Sep 22
    20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event Sep 22 20:01:35 eric kernel: RIP:
    0010:power_supply_uevent+0xee/0x1d0 ... Sep 22 20:01:35 eric kernel: ? asm_exc_page_fault+0x26/0x30 Sep 22
    20:01:35 eric kernel: ? power_supply_uevent+0xee/0x1d0 Sep 22 20:01:35 eric kernel: ?
    power_supply_uevent+0x10d/0x1d0 Sep 22 20:01:35 eric kernel: dev_uevent+0x10f/0x2d0 Sep 22 20:01:35 eric
    kernel: kobject_uevent_env+0x291/0x680 Sep 22 20:01:35 eric kernel: ---truncated--- (CVE-2023-52478)

  - In the Linux kernel, the following vulnerability has been resolved: x86/srso: Add SRSO mitigation for
    Hygon processors Add mitigation for the speculative return stack overflow vulnerability which exists on
    Hygon processors too. (CVE-2023-52482)

  - 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: wifi: mac80211: fix potential key use-
    after-free When ieee80211_key_link() is called by ieee80211_gtk_rekey_add() but returns 0 due to KRACK
    protection (identical key reinstall), ieee80211_gtk_rekey_add() will still return a pointer into the key,
    in a potential use-after-free. This normally doesn't happen since it's only called by iwlwifi in case of
    WoWLAN rekey offload which has its own KRACK protection, but still better to fix, do that by returning an
    error code and converting that to success on the cfg80211 boundary only, leaving the error for bad callers
    of ieee80211_gtk_rekey_add(). (CVE-2023-52530)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix a memory
    corruption issue A few lines above, space is kzalloc()'ed for: sizeof(struct iwl_nvm_data) + sizeof(struct
    ieee80211_channel) + sizeof(struct ieee80211_rate) 'mvm->nvm_data' is a 'struct iwl_nvm_data', so it is
    fine. At the end of this structure, there is the 'channels' flex array. Each element is of type 'struct
    ieee80211_channel'. So only 1 element is allocated in this array. When doing:
    mvm->nvm_data->bands[0].channels = mvm->nvm_data->channels; We point at the first element of the
    'channels' flex array. So this is fine. However, when doing: mvm->nvm_data->bands[0].bitrates = (void
    *)((u8 *)mvm->nvm_data->channels + 1); because of the (u8 *) cast, we add only 1 to the address of the
    beginning of the flex array. It is likely that we want point at the 'struct ieee80211_rate' allocated just
    after. Remove the spurious casting so that the pointer arithmetic works as expected. (CVE-2023-52531)

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

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

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

  - A flaw was found in the Netfilter subsystem in the Linux kernel. The issue is in the nft_byteorder_eval()
    function, where the code iterates through a loop and writes to the `dst` array. On each iteration, 8 bytes
    are written, but `dst` is an array of u32, so each element only has space for 4 bytes. That means every
    iteration overwrites part of the previous element corrupting this array of u32. This flaw allows a local
    user to cause a denial of service or potentially break NetFilter functionality. (CVE-2024-0607)

  - A vulnerability was reported in the Open vSwitch sub-component in the Linux Kernel. The flaw occurs when a
    recursive operation of code push recursively calls into the code block. The OVS module does not validate
    the stack depth, pushing too many frames and causing a stack overflow. As a result, this can lead to a
    crash or other related issues. (CVE-2024-1151)

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

  - copy_params in drivers/md/dm-ioctl.c in the Linux kernel through 6.7.1 can attempt to allocate more than
    INT_MAX bytes, and crash, because of a missing param_kernel->data_size check. This is related to
    ctl_ioctl. (CVE-2024-23851)

  - In the Linux kernel, the following vulnerability has been resolved: tls: fix race between tx work
    scheduling and socket close Similarly to previous commit, the submitting thread (recvmsg/sendmsg) may exit
    as soon as the async crypto handler calls complete(). Reorder scheduling the work before calling
    complete(). This seems more logical in the first place, as it's the inverse order of what the submitting
    thread will do. (CVE-2024-26585)

  - In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix NULL
    pointer dereference in error path When calling mlxsw_sp_acl_tcam_region_destroy() from an error path after
    failing to attach the region to an ACL group, we hit a NULL pointer dereference upon 'region->group->tcam'
    [1]. Fix by retrieving the 'tcam' pointer using mlxsw_sp_acl_to_tcam(). [1] BUG: kernel NULL pointer
    dereference, address: 0000000000000000 [...] RIP: 0010:mlxsw_sp_acl_tcam_region_destroy+0xa0/0xd0 [...]
    Call Trace: mlxsw_sp_acl_tcam_vchunk_get+0x88b/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0
    mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0
    fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90
    rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390
    netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0
    do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b (CVE-2024-26595)

  - 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: tomoyo: fix UAF write bug in
    tomoyo_write_control() Since tomoyo_write_control() updates head->write_buf when write() of long lines is
    requested, we need to fetch head->write_buf after head->io_sem is held. Otherwise, concurrent write()
    requests can cause use-after-free-write and double-free problems. (CVE-2024-26622)

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/1050549");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1186484");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1200599");
  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/1218450");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1218527");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1218915");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1219127");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1219146");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1219295");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1219653");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1219827");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1219835");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220187");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220238");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220240");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220241");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220250");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220330");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220340");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220344");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220409");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220421");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220436");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220444");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220459");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220468");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220482");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220526");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220570");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220575");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220599");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220607");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220613");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220638");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220641");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220649");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220700");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220735");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220767");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220796");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220825");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220831");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220845");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220860");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220861");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220863");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220870");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220930");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220931");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220932");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220957");
  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/1221287");
  # https://lists.suse.com/pipermail/sle-security-updates/2024-March/018185.html
  script_set_attribute(attribute:"see_also", value:"http://www.nessus.org/u?ca852908");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2019-25162");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2020-36777");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2020-36784");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46906");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46915");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46921");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46924");
  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-46932");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46953");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46974");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46991");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46992");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47013");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47054");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47076");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47077");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47078");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2022-48627");
  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-46343");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52340");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52429");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52443");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52445");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52449");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52451");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52464");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52475");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52478");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52482");
  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-52530");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52531");
  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-52574");
  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-52605");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-0607");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-1151");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-23849");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-23851");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26585");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26595");
  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-26622");
  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:U/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:U/RL:O/RC:C");
  script_set_attribute(attribute:"cvss_score_source", value:"CVE-2023-52464");

  script_set_attribute(attribute:"exploitability_ease", value:"No known exploits are available");
  script_set_attribute(attribute:"exploit_available", value:"false");

  script_set_attribute(attribute:"vuln_publication_date", value:"2021/07/14");
  script_set_attribute(attribute:"patch_publication_date", value:"2024/03/22");
  script_set_attribute(attribute:"plugin_publication_date", value:"2024/03/23");

  script_set_attribute(attribute:"plugin_type", value:"local");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:cluster-md-kmp-rt");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:dlm-kmp-rt");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:gfs2-kmp-rt");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-devel-rt");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-rt");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-rt-base");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-rt-devel");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-rt_debug");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-rt_debug-devel");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-source-rt");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-syms-rt");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:ocfs2-kmp-rt");
  script_set_attribute(attribute:"cpe", value:"cpe:/o:novell:suse_linux:12");
  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)") audit(AUDIT_OS_NOT, "SUSE");
var os_ver = pregmatch(pattern: "^(SLE(S|D)\d+)", string:os_release);
if (isnull(os_ver)) audit(AUDIT_UNKNOWN_APP_VER, 'SUSE');
os_ver = os_ver[1];
if (! preg(pattern:"^(SLES12)$", string:os_ver)) audit(AUDIT_OS_NOT, 'SUSE SLES12', 'SUSE (' + 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 (' + os_ver + ')', cpu);

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

var pkgs = [
    {'reference':'cluster-md-kmp-rt-4.12.14-10.171.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SUSE-Linux-Enterprise-RT-release-12.5']},
    {'reference':'dlm-kmp-rt-4.12.14-10.171.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SUSE-Linux-Enterprise-RT-release-12.5']},
    {'reference':'gfs2-kmp-rt-4.12.14-10.171.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SUSE-Linux-Enterprise-RT-release-12.5']},
    {'reference':'kernel-devel-rt-4.12.14-10.171.1', 'sp':'5', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SUSE-Linux-Enterprise-RT-release-12.5']},
    {'reference':'kernel-rt-4.12.14-10.171.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SUSE-Linux-Enterprise-RT-release-12.5']},
    {'reference':'kernel-rt-base-4.12.14-10.171.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SUSE-Linux-Enterprise-RT-release-12.5']},
    {'reference':'kernel-rt-devel-4.12.14-10.171.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SUSE-Linux-Enterprise-RT-release-12.5']},
    {'reference':'kernel-rt_debug-4.12.14-10.171.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SUSE-Linux-Enterprise-RT-release-12.5']},
    {'reference':'kernel-rt_debug-devel-4.12.14-10.171.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SUSE-Linux-Enterprise-RT-release-12.5']},
    {'reference':'kernel-source-rt-4.12.14-10.171.1', 'sp':'5', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SUSE-Linux-Enterprise-RT-release-12.5']},
    {'reference':'kernel-syms-rt-4.12.14-10.171.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SUSE-Linux-Enterprise-RT-release-12.5']},
    {'reference':'ocfs2-kmp-rt-4.12.14-10.171.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SUSE-Linux-Enterprise-RT-release-12.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-rt / dlm-kmp-rt / gfs2-kmp-rt / kernel-devel-rt / etc');
}