The remote SUSE Linux SLES15 host has a package installed that is affected by multiple vulnerabilities as referenced in the SUSE-SU-2024:1740-1 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: ipvlan: Fix out-of-bound bugs caused     by unset skb->mac_header If an AF_PACKET socket is used to send packets through ipvlan and the default     xmit function of the AF_PACKET socket is changed from dev_queue_xmit() to packet_direct_xmit() via     setsockopt() with the option name of PACKET_QDISC_BYPASS, the skb->mac_header may not be reset and remains     as the initial value of 65535, this may trigger slab-out-of-bounds bugs as following:
    ================================================================= UG: KASAN: slab-out-of-bounds in     ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan] PU: 2 PID: 1768 Comm: raw_send Kdump: loaded Not tainted     6.0.0-rc4+ #6 ardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 all Trace:
    print_address_description.constprop.0+0x1d/0x160 print_report.cold+0x4f/0x112 kasan_report+0xa3/0x130     ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan] ipvlan_start_xmit+0x29/0xa0 [ipvlan] __dev_direct_xmit+0x2e2/0x380     packet_direct_xmit+0x22/0x60 packet_snd+0x7c9/0xc40 sock_sendmsg+0x9a/0xa0 __sys_sendto+0x18a/0x230
    __x64_sys_sendto+0x74/0x90 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd The root cause     is: 1. packet_snd() only reset skb->mac_header when sock->type is SOCK_RAW and skb->protocol is not     specified as in packet_parse_headers() 2. packet_direct_xmit() doesn't reset skb->mac_header as     dev_queue_xmit() In this case, skb->mac_header is 65535 when ipvlan_xmit_mode_l2() is called. So when     ipvlan_xmit_mode_l2() gets mac header with eth_hdr() which use skb->head + skb->mac_header, out-of-bound     access occurs. This patch replaces eth_hdr() with skb_eth_hdr() in ipvlan_xmit_mode_l2() and reset mac     header in multicast to solve this out-of-bound bug. (CVE-2022-48651)

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

  - A race condition was found in the GSM 0710 tty multiplexor in the Linux kernel. This issue occurs when two     threads execute the GSMIOC_SETCONF ioctl on the same tty file descriptor with the gsm line discipline     enabled, and can lead to a use-after-free problem on a struct gsm_dlci while restarting the gsm mux. This     could allow a local unprivileged user to escalate their privileges on the system. (CVE-2023-6546)

  - 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: wifi: iwlwifi: fix a memory corruption     iwl_fw_ini_trigger_tlv::data is a pointer to a __le32, which means that if we copy to     iwl_fw_ini_trigger_tlv::data + offset while offset is in bytes, we'll write past the buffer.
    (CVE-2024-26610)

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

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

Detections

Analytics

SUSE SLES15 Security Update : kernel (Live Patch 21 for SLE 15 SP4) (SUSE-SU-2024:1740-1)

high Nessus Plugin ID 197589

Version 1.3