7.8 High
CVSS3
Attack Vector
LOCAL
Attack Complexity
LOW
Privileges Required
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
HIGH
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
7.8 High
AI Score
Confidence
High
0.0004 Low
EPSS
Percentile
10.5%
The remote SUSE Linux SLED15 / SLED_SAP15 / SLES15 / SLES_SAP15 / openSUSE 15 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2024:0858-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: fs/mount_setattr: always cleanup mount_kattr Make sure that finish_mount_kattr() is called after mount_kattr was succesfully built in both the success and failure case to prevent leaking any references we took when we built it. We returned early if path lookup failed thereby risking to leak an additional reference we took when building mount_kattr when an idmapped mount was requested. (CVE-2021-46923)
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: 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)
This CVE was assigned by Intel. Please see CVE-2023-28746 on CVE.org for more information.
(CVE-2023-28746)
A use-after-free vulnerability in the Linux kernel’s netfilter: nf_tables component can be exploited to achieve local privilege escalation. Addition and removal of rules from chain bindings within the same transaction causes leads to use-after-free. We recommend upgrading past commit f15f29fd4779be8a418b66e9d52979bb6d6c2325. (CVE-2023-5197)
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: uio: Fix use-after-free in uio_open core-1 core-2 ------------------------------------------------------- uio_unregister_device uio_open idev = idr_find() device_unregister(&idev->dev) put_device(&idev->dev) uio_device_release get_device(&idev->dev) kfree(idev) uio_free_minor(minor) uio_release put_device(&idev->dev) kfree(idev)
------------------------------------------------------- In the core-1 uio_unregister_device(), the device_unregister will kfree idev when the idev->dev kobject ref is 1. But after core-1 device_unregister, put_device and before doing kfree, the core-2 may get_device. Then: 1. After core-1 kfree idev, the core-2 will do use-after-free for idev. 2. When core-2 do uio_release and put_device, the idev will be double freed. To address this issue, we can get idev atomic & inc idev reference with minor_lock.
(CVE-2023-52439)
In the Linux kernel, the following vulnerability has been resolved: apparmor: avoid crash when parsed profile name is empty When processing a packed profile in unpack_profile() described like profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {…} a string :samba-dcerpcd is unpacked as a fully-qualified name and then passed to aa_splitn_fqname(). aa_splitn_fqname() treats :samba-dcerpcd as only containing a namespace. Thus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Later aa_alloc_profile() crashes as the new profile name is NULL now. general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 6 PID: 1657 Comm: apparmor_parser Not tainted 6.7.0-rc2-dirty #16 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 RIP: 0010:strlen+0x1e/0xa0 Call Trace: <TASK> ? strlen+0x1e/0xa0 aa_policy_init+0x1bb/0x230 aa_alloc_profile+0xb1/0x480 unpack_profile+0x3bc/0x4960 aa_unpack+0x309/0x15e0 aa_replace_profiles+0x213/0x33c0 policy_update+0x261/0x370 profile_replace+0x20e/0x2a0 vfs_write+0x2af/0xe00 ksys_write+0x126/0x250 do_syscall_64+0x46/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 </TASK> —[ end trace 0000000000000000 ]— RIP:
0010:strlen+0x1e/0xa0 It seems such behaviour of aa_splitn_fqname() is expected and checked in other places where it is called (e.g. aa_remove_profiles). Well, there is an explicit comment a ns name without a following profile is allowed inside. AFAICS, nothing can prevent unpacked name to be in form like :samba-dcerpcd - it is passed from userspace. Deny the whole profile set replacement in such case and inform user with EPROTO and an explaining message. Found by Linux Verification Center (linuxtesting.org).
(CVE-2023-52443)
In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix use after free on context disconnection Upon module load, a kthread is created targeting the pvr2_context_thread_func function, which may call pvr2_context_destroy and thus call kfree() on the context object. However, that might happen before the usb hub_event handler is able to notify the driver. This patch adds a sanity check before the invalid read reported by syzbot, within the context disconnection call stack. (CVE-2023-52445)
In the Linux kernel, the following vulnerability has been resolved: bpf: Defer the free of inner map when necessary When updating or deleting an inner map in map array or map htab, the map may still be accessed by non-sleepable program or sleepable program. However bpf_map_fd_put_ptr() decreases the ref-counter of the inner map directly through bpf_map_put(), if the ref-counter is the last one (which is true for most cases), the inner map will be freed by ops->map_free() in a kworker. But for now, most .map_free() callbacks don’t use synchronize_rcu() or its variants to wait for the elapse of a RCU grace period, so after the invocation of ops->map_free completes, the bpf program which is accessing the inner map may incur use-after-free problem. Fix the free of inner map by invoking bpf_map_free_deferred() after both one RCU grace period and one tasks trace RCU grace period if the inner map has been removed from the outer map before. The deferment is accomplished by using call_rcu() or call_rcu_tasks_trace() when releasing the last ref-counter of bpf map. The newly-added rcu_head field in bpf_map shares the same storage space with work field to reduce the size of bpf_map. (CVE-2023-52447)
In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump Syzkaller has reported a NULL pointer dereference when accessing rgd->rd_rgl in gfs2_rgrp_dump(). This can happen when creating rgd->rd_gl fails in read_rindex_entry(). Add a NULL pointer check in gfs2_rgrp_dump() to prevent that. (CVE-2023-52448)
In the Linux kernel, the following vulnerability has been resolved: mtd: Fix gluebi NULL pointer dereference caused by ftl notifier If both ftl.ko and gluebi.ko are loaded, the notifier of ftl triggers NULL pointer dereference when trying to access gluebi->desc’ in gluebi_read(). ubi_gluebi_init ubi_register_volume_notifier ubi_enumerate_volumes ubi_notify_all gluebi_notify nb->notifier_call() gluebi_create mtd_device_register mtd_device_parse_register add_mtd_device blktrans_notify_add not->add() ftl_add_mtd tr->add_mtd() scan_header mtd_read mtd_read_oob mtd_read_oob_std gluebi_read mtd->read() gluebi->desc - NULL Detailed reproduction information available at the Link [1], In the normal case, obtain gluebi->desc in the gluebi_get_device(), and access gluebi->desc in the gluebi_read(). However, gluebi_get_device() is not executed in advance in the ftl_add_mtd() process, which leads to NULL pointer dereference. The solution for the gluebi module is to run jffs2 on the UBI volume without considering working with ftl or mtdblock [2]. Therefore, this problem can be avoided by preventing gluebi from creating the mtdblock device after creating mtd partition of the type MTD_UBIVOLUME. (CVE-2023-52449)
In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/memhp: Fix access beyond end of drmem array dlpar_memory_remove_by_index() may access beyond the bounds of the drmem lmb array when the LMB lookup fails to match an entry with the given DRC index. When the search fails, the cursor is left pointing to &drmem_info->lmbs[drmem_info->n_lmbs], which is one element past the last valid entry in the array. The debug message at the end of the function then dereferences this pointer:
pr_debug(Failed to hot-remove memory at %llx\n, lmb->base_addr); This was found by inspection and confirmed with KASAN: pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234 ================================================================== BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658 Read of size 8 at addr c000000364e97fd0 by task bash/949 dump_stack_lvl+0xa4/0xfc (unreliable) print_report+0x214/0x63c kasan_report+0x140/0x2e0
__asan_load8+0xa8/0xe0 dlpar_memory+0x298/0x1658 handle_dlpar_errorlog+0x130/0x1d0 dlpar_store+0x18c/0x3e0 kobj_attr_store+0x68/0xa0 sysfs_kf_write+0xc4/0x110 kernfs_fop_write_iter+0x26c/0x390 vfs_write+0x2d4/0x4e0 ksys_write+0xac/0x1a0 system_call_exception+0x268/0x530 system_call_vectored_common+0x15c/0x2ec Allocated by task 1: kasan_save_stack+0x48/0x80 kasan_set_track+0x34/0x50 kasan_save_alloc_info+0x34/0x50 __kasan_kmalloc+0xd0/0x120 __kmalloc+0x8c/0x320 kmalloc_array.constprop.0+0x48/0x5c drmem_init+0x2a0/0x41c do_one_initcall+0xe0/0x5c0 kernel_init_freeable+0x4ec/0x5a0 kernel_init+0x30/0x1e0 ret_from_kernel_user_thread+0x14/0x1c The buggy address belongs to the object at c000000364e80000 which belongs to the cache kmalloc-128k of size 131072 The buggy address is located 0 bytes to the right of allocated 98256-byte region [c000000364e80000, c000000364e97fd0) ================================================================== pseries-hotplug-mem:
Failed to hot-remove memory at 0 Log failed lookups with a separate message and dereference the cursor only when it points to a valid entry. (CVE-2023-52451)
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix accesses to uninit stack slots Privileged programs are supposed to be able to read uninitialized stack memory (ever since 6715df8d5) but, before this patch, these accesses were permitted inconsistently. In particular, accesses were permitted above state->allocated_stack, but not below it. In other words, if the stack was already large enough, the access was permitted, but otherwise the access was rejected instead of being allowed to grow the stack. This undesired rejection was happening in two places: - in check_stack_slot_within_bounds() - in check_stack_range_initialized() This patch arranges for these accesses to be permitted. A bunch of tests that were relying on the old rejection had to change; all of them were changed to add also run unprivileged, in which case the old behavior persists. One tests couldn’t be updated - global_func16 - because it can’t run unprivileged for other reasons. This patch also fixes the tracking of the stack size for variable-offset reads. This second fix is bundled in the same commit as the first one because they’re inter-related. Before this patch, writes to the stack using registers containing a variable offset (as opposed to registers with fixed, known values) were not properly contributing to the function’s needed stack size. As a result, it was possible for a program to verify, but then to attempt to read out-of-bounds data at runtime because a too small stack had been allocated for it. Each function tracks the size of the stack it needs in bpf_subprog_info.stack_depth, which is maintained by update_stack_depth(). For regular memory accesses, check_mem_access() was calling update_state_depth() but it was passing in only the fixed part of the offset register, ignoring the variable offset. This was incorrect; the minimum possible value of that register should be used instead.
This tracking is now fixed by centralizing the tracking of stack size in grow_stack_state(), and by lifting the calls to grow_stack_state() to check_stack_access_within_bounds() as suggested by Andrii. The code is now simpler and more convincingly tracks the correct maximum stack size.
check_stack_range_initialized() can now rely on enough stack having been allocated for the access; this helps with the fix for the first issue. A few tests were changed to also check the stack depth computation. The one that fails without this patch is verifier_var_off:stack_write_priv_vs_unpriv.
(CVE-2023-52452)
In the Linux kernel, the following vulnerability has been resolved: serial: imx: fix tx statemachine deadlock When using the serial port as RS485 port, the tx statemachine is used to control the RTS pin to drive the RS485 transceiver TX_EN pin. When the TTY port is closed in the middle of a transmission (for instance during userland application crash), imx_uart_shutdown disables the interface and disables the Transmission Complete interrupt. afer that, imx_uart_stop_tx bails on an incomplete transmission, to be retriggered by the TC interrupt. This interrupt is disabled and therefore the tx statemachine never transitions out of SEND. The statemachine is in deadlock now, and the TX_EN remains low, making the interface useless. imx_uart_stop_tx now checks for incomplete transmission AND whether TC interrupts are enabled before bailing to be retriggered. This makes sure the state machine handling is reached, and is properly set to WAIT_AFTER_SEND. (CVE-2023-52456)
In the Linux kernel, the following vulnerability has been resolved: serial: 8250: omap: Don’t skip resource freeing if pm_runtime_resume_and_get() failed Returning an error code from .remove() makes the driver core emit the little helpful error message: remove callback returned a non-zero value. This will be ignored. and then remove the device anyhow. So all resources that were not freed are leaked in this case.
Skipping serial8250_unregister_port() has the potential to keep enough of the UART around to trigger a use-after-free. So replace the error return (and with it the little helpful error message) by a more useful error message and continue to cleanup. (CVE-2023-52457)
In the Linux kernel, the following vulnerability has been resolved: efivarfs: force RO when remounting if SetVariable is not supported If SetVariable at runtime is not supported by the firmware we never assign a callback for that function. At the same time mount the efivarfs as RO so no one can call that. However, we never check the permission flags when someone remounts the filesystem as RW. As a result this leads to a crash looking like this: $ mount -o remount,rw /sys/firmware/efi/efivars $ efi-updatevar -f PK.auth PK [ 303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 303.280482] Mem abort info: [ 303.280854] ESR = 0x0000000086000004 [ 303.281338] EC = 0x21: IABT (current EL), IL = 32 bits [ 303.282016] SET = 0, FnV = 0 [ 303.282414] EA = 0, S1PTW = 0 [ 303.282821] FSC = 0x04:
level 0 translation fault [ 303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000 [ 303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 303.286076] Internal error:
Oops: 0000000086000004 [#1] PREEMPT SMP [ 303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6 [ 303.288586] CPU: 1 PID: 755 Comm:
efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1 [ 303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023 [ 303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=–) [ 303.292123] pc : 0x0 [ 303.292443] lr :
efivar_set_variable_locked+0x74/0xec [ 303.293156] sp : ffff800008673c10 [ 303.293619] x29:
ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000 [ 303.294592] x26: 0000000000000800 x25:
ffff000002467400 x24: 0000000000000027 [ 303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21:
ffff000002467000 [ 303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000 [ 303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54 [ 303.298495] x14:
ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4 [ 303.299453] x11: ffff000002af7b01 x10:
0000000000000003 x9 : 0000000000000002 [ 303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 :
0000000000a85201 [ 303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc [ 303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000 [ 303.303341] Call trace: [ 303.303679] 0x0 [ 303.303938] efivar_entry_set_get_size+0x98/0x16c [ 303.304585] efivarfs_file_write+0xd0/0x1a4 [ 303.305148] vfs_write+0xc4/0x2e4 [ 303.305601] ksys_write+0x70/0x104 [ 303.306073] __arm64_sys_write+0x1c/0x28 [ 303.306622] invoke_syscall+0x48/0x114 [ 303.307156] el0_svc_common.constprop.0+0x44/0xec [ 303.307803] do_el0_svc+0x38/0x98 [ 303.308268] el0_svc+0x2c/0x84 [ 303.308702] el0t_64_sync_handler+0xf4/0x120 [ 303.309293] el0t_64_sync+0x190/0x194 [ 303.309794] Code:
??? ??? ??? ??? (???) [ 303.310612] —[ end trace 0000000000000000 ]— Fix this by adding a .reconfigure() function to the fs operations which we can use to check the requested flags and deny anything that’s not RO if the firmware doesn’t implement SetVariable at runtime. (CVE-2023-52463)
In the Linux kernel, the following vulnerability has been resolved: EDAC/thunderx: Fix possible out-of- bounds string access Enabling -Wstringop-overflow globally exposes a warning for a common bug in the usage of strncat(): drivers/edac/thunderx_edac.c: In function ‘thunderx_ocx_com_threaded_isr’:
drivers/edac/thunderx_edac.c:1136:17: error: ‘strncat’ specified bound 1024 equals destination size [-Werror=stringop-overflow=] 1136 | strncat(msg, other, OCX_MESSAGE_SIZE); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ … 1145 | strncat(msg, other, OCX_MESSAGE_SIZE); … 1150 | strncat(msg, other, OCX_MESSAGE_SIZE); … Apparently the author of this driver expected strncat() to behave the way that strlcat() does, which uses the size of the destination buffer as its third argument rather than the length of the source buffer. The result is that there is no check on the size of the allocated buffer. Change it to strlcat(). [ bp: Trim compiler output, fixup commit message. ] (CVE-2023-52464)
In the Linux kernel, the following vulnerability has been resolved: 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)
A use-after-free vulnerability in the Linux kernel’s netfilter: nf_tables component can be exploited to achieve local privilege escalation. The function nft_pipapo_walk did not skip inactive elements during set walk which could lead double deactivations of PIPAPO (Pile Packet Policies) elements, leading to use- after-free. We recommend upgrading past commit 317eb9685095678f2c9f5a8189de698c5354316a. (CVE-2023-6817)
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)
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)
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 before 6.6.7, an untrusted VMM can trigger int80 syscall handling at any given point.
This is related to arch/x86/coco/tdx/tdx.c and arch/x86/mm/mem_encrypt_amd.c. (CVE-2024-25744)
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 stack corruption When tc filters are first added to a net device, the corresponding local port gets bound to an ACL group in the device. The group contains a list of ACLs. In turn, each ACL points to a different TCAM region where the filters are stored. During forwarding, the ACLs are sequentially evaluated until a match is found. One reason to place filters in different regions is when they are added with decreasing priorities and in an alternating order so that two consecutive filters can never fit in the same region because of their key usage. In Spectrum-2 and newer ASICs the firmware started to report that the maximum number of ACLs in a group is more than 16, but the layout of the register that configures ACL groups (PAGT) was not updated to account for that. It is therefore possible to hit stack corruption [1] in the rare case where more than 16 ACLs in a group are required. Fix by limiting the maximum ACL group size to the minimum between what the firmware reports and the maximum ACLs that fit in the PAGT register. Add a test case to make sure the machine does not crash when this condition is hit. [1] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120 […] dump_stack_lvl+0x36/0x50 panic+0x305/0x330 __stack_chk_fail+0x15/0x20 mlxsw_sp_acl_tcam_group_update+0x116/0x120 mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110 mlxsw_sp_acl_tcam_vchunk_get+0x492/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-26586)
In the Linux kernel, the following vulnerability has been resolved: bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off for validation.
However, variable offset ptr alu is not prohibited for this ptr kind. So the variable offset is not checked. The following prog is accepted: func#0 @0 0: R1=ctx() R10=fp0 0: (bf) r6 = r1 ; R1=ctx() R6_w=ctx() 1: (79) r7 = *(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flow_keys() 2: (b7) r8 = 1024 ; R8_w=1024 3:
(37) r8 /= 1 ; R8_w=scalar() 4: (57) r8 &= 1024 ; R8_w=scalar(smin=smin32=0, smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400)) 5: (0f) r7 += r8 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &= 1024 mark_precise:
frame0: regs=r8 stack= before 3: (37) r8 /= 1 mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 = 1024 6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off =(0x0; 0x400)) R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024, var_off=(0x0; 0x400)) 6: (79) r0 = *(u64 *)(r7 +0) ; R0_w=scalar() 7: (95) exit This prog loads flow_keys to r7, and adds the variable offset r8 to r7, and finally causes out-of-bounds access: BUG: unable to handle page fault for address: ffffc90014c80038 […] Call Trace: <TASK> bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline] __bpf_prog_run include/linux/filter.h:651 [inline] bpf_prog_run include/linux/filter.h:658 [inline] bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline] bpf_flow_dissect+0x15f/0x350 net/core/flow_dissector.c:991 bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359 bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline] __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475
__do_sys_bpf kernel/bpf/syscall.c:5561 [inline] __se_sys_bpf kernel/bpf/syscall.c:5559 [inline]
__x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Fix this by rejecting ptr alu with variable offset on flow_keys. Applying the patch rejects the program with R7 pointer arithmetic on flow_keys prohibited. (CVE-2024-26589)
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix re-attachment branch in bpf_tracing_prog_attach The following case can cause a crash due to missing attach_btf: 1) load rawtp program 2) load fentry program with rawtp as target_fd 3) create tracing link for fentry program with target_fd = 0 4) repeat 3 In the end we have: - prog->aux->dst_trampoline == NULL - tgt_prog == NULL (because we did not provide target_fd to link_create) - prog->aux->attach_btf == NULL (the program was loaded with attach_prog_fd=X) - the program was loaded for tgt_prog but we have no way to find out which one BUG: kernel NULL pointer dereference, address: 0000000000000058 Call Trace: <TASK> ? __die+0x20/0x70 ? page_fault_oops+0x15b/0x430 ? fixup_exception+0x22/0x330 ? exc_page_fault+0x6f/0x170 ? asm_exc_page_fault+0x22/0x30 ? bpf_tracing_prog_attach+0x279/0x560 ? btf_obj_id+0x5/0x10 bpf_tracing_prog_attach+0x439/0x560 __sys_bpf+0x1cf4/0x2de0 __x64_sys_bpf+0x1c/0x30 do_syscall_64+0x41/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Return -EINVAL in this situation.
(CVE-2024-26591)
In the Linux kernel, the following vulnerability has been resolved: i2c: i801: Fix block process call transactions According to the Intel datasheets, software must reset the block buffer index twice for block process call transactions: once before writing the outgoing data to the buffer, and once again before reading the incoming data from the buffer. The driver is currently missing the second reset, causing the wrong portion of the block buffer to be read. (CVE-2024-26593)
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: KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache There is a potential UAF scenario in the case of an LPI translation cache hit racing with an operation that invalidates the cache, such as a DISCARD ITS command. The root of the problem is that vgic_its_check_cache() does not elevate the refcount on the vgic_irq before dropping the lock that serializes refcount changes. Have vgic_its_check_cache() raise the refcount on the returned vgic_irq and add the corresponding decrement after queueing the interrupt. (CVE-2024-26598)
In the Linux kernel, the following vulnerability has been resolved: 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: x86/fpu: Stop relying on userspace for info to fault in xsave buffer Before this change, the expected size of the user space buffer was taken from fx_sw->xstate_size. fx_sw->xstate_size can be changed from user-space, so it is possible construct a sigreturn frame where: * fx_sw->xstate_size is smaller than the size required by valid bits in fx_sw->xfeatures. * user-space unmaps parts of the sigrame fpu buffer so that not all of the buffer required by xrstor is accessible. In this case, xrstor tries to restore and accesses the unmapped area which results in a fault. But fault_in_readable succeeds because buf + fx_sw->xstate_size is within the still mapped area, so it goes back and tries xrstor again. It will spin in this loop forever. Instead, fault in the maximum size which can be touched by XRSTOR (taken from fpstate->user_size). [ dhansen: tweak subject / changelog ] (CVE-2024-26603)
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.
#%NASL_MIN_LEVEL 80900
##
# (C) Tenable, Inc.
#
# The package checks in this plugin were extracted from
# SUSE update advisory SUSE-SU-2024:0858-1. The text itself
# is copyright (C) SUSE.
##
include('compat.inc');
if (description)
{
script_id(192011);
script_version("1.3");
script_set_attribute(attribute:"plugin_modification_date", value:"2024/04/18");
script_cve_id(
"CVE-2019-25162",
"CVE-2021-46923",
"CVE-2021-46924",
"CVE-2021-46932",
"CVE-2023-5197",
"CVE-2023-6817",
"CVE-2023-28746",
"CVE-2023-52340",
"CVE-2023-52429",
"CVE-2023-52439",
"CVE-2023-52443",
"CVE-2023-52445",
"CVE-2023-52447",
"CVE-2023-52448",
"CVE-2023-52449",
"CVE-2023-52451",
"CVE-2023-52452",
"CVE-2023-52456",
"CVE-2023-52457",
"CVE-2023-52463",
"CVE-2023-52464",
"CVE-2023-52475",
"CVE-2023-52478",
"CVE-2024-0607",
"CVE-2024-1151",
"CVE-2024-23849",
"CVE-2024-23850",
"CVE-2024-23851",
"CVE-2024-25744",
"CVE-2024-26585",
"CVE-2024-26586",
"CVE-2024-26589",
"CVE-2024-26591",
"CVE-2024-26593",
"CVE-2024-26595",
"CVE-2024-26598",
"CVE-2024-26602",
"CVE-2024-26603",
"CVE-2024-26622"
);
script_xref(name:"SuSE", value:"SUSE-SU-2024:0858-1");
script_name(english:"SUSE SLED15 / SLES15 / openSUSE 15 Security Update : kernel (SUSE-SU-2024:0858-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 SLED15 / SLED_SAP15 / SLES15 / SLES_SAP15 / openSUSE 15 host has packages installed that are
affected by multiple vulnerabilities as referenced in the SUSE-SU-2024:0858-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: fs/mount_setattr: always cleanup
mount_kattr Make sure that finish_mount_kattr() is called after mount_kattr was succesfully built in both
the success and failure case to prevent leaking any references we took when we built it. We returned early
if path lookup failed thereby risking to leak an additional reference we took when building mount_kattr
when an idmapped mount was requested. (CVE-2021-46923)
- 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: 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)
- This CVE was assigned by Intel. Please see CVE-2023-28746 on CVE.org for more information.
(CVE-2023-28746)
- A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to
achieve local privilege escalation. Addition and removal of rules from chain bindings within the same
transaction causes leads to use-after-free. We recommend upgrading past commit
f15f29fd4779be8a418b66e9d52979bb6d6c2325. (CVE-2023-5197)
- 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: uio: Fix use-after-free in uio_open
core-1 core-2 ------------------------------------------------------- uio_unregister_device uio_open idev
= idr_find() device_unregister(&idev->dev) put_device(&idev->dev) uio_device_release
get_device(&idev->dev) kfree(idev) uio_free_minor(minor) uio_release put_device(&idev->dev) kfree(idev)
------------------------------------------------------- In the core-1 uio_unregister_device(), the
device_unregister will kfree idev when the idev->dev kobject ref is 1. But after core-1 device_unregister,
put_device and before doing kfree, the core-2 may get_device. Then: 1. After core-1 kfree idev, the core-2
will do use-after-free for idev. 2. When core-2 do uio_release and put_device, the idev will be double
freed. To address this issue, we can get idev atomic & inc idev reference with minor_lock.
(CVE-2023-52439)
- In the Linux kernel, the following vulnerability has been resolved: apparmor: avoid crash when parsed
profile name is empty When processing a packed profile in unpack_profile() described like profile
:ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...} a string :samba-dcerpcd is unpacked as
a fully-qualified name and then passed to aa_splitn_fqname(). aa_splitn_fqname() treats :samba-dcerpcd
as only containing a namespace. Thus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Later
aa_alloc_profile() crashes as the new profile name is NULL now. general protection fault, probably for
non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range
[0x0000000000000000-0x0000000000000007] CPU: 6 PID: 1657 Comm: apparmor_parser Not tainted 6.7.0-rc2-dirty
#16 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 RIP: 0010:strlen+0x1e/0xa0 Call Trace: <TASK> ?
strlen+0x1e/0xa0 aa_policy_init+0x1bb/0x230 aa_alloc_profile+0xb1/0x480 unpack_profile+0x3bc/0x4960
aa_unpack+0x309/0x15e0 aa_replace_profiles+0x213/0x33c0 policy_update+0x261/0x370
profile_replace+0x20e/0x2a0 vfs_write+0x2af/0xe00 ksys_write+0x126/0x250 do_syscall_64+0x46/0xf0
entry_SYSCALL_64_after_hwframe+0x6e/0x76 </TASK> ---[ end trace 0000000000000000 ]--- RIP:
0010:strlen+0x1e/0xa0 It seems such behaviour of aa_splitn_fqname() is expected and checked in other
places where it is called (e.g. aa_remove_profiles). Well, there is an explicit comment a ns name without
a following profile is allowed inside. AFAICS, nothing can prevent unpacked name to be in form like
:samba-dcerpcd - it is passed from userspace. Deny the whole profile set replacement in such case and
inform user with EPROTO and an explaining message. Found by Linux Verification Center (linuxtesting.org).
(CVE-2023-52443)
- In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix use after free on
context disconnection Upon module load, a kthread is created targeting the pvr2_context_thread_func
function, which may call pvr2_context_destroy and thus call kfree() on the context object. However, that
might happen before the usb hub_event handler is able to notify the driver. This patch adds a sanity check
before the invalid read reported by syzbot, within the context disconnection call stack. (CVE-2023-52445)
- In the Linux kernel, the following vulnerability has been resolved: bpf: Defer the free of inner map when
necessary When updating or deleting an inner map in map array or map htab, the map may still be accessed
by non-sleepable program or sleepable program. However bpf_map_fd_put_ptr() decreases the ref-counter of
the inner map directly through bpf_map_put(), if the ref-counter is the last one (which is true for most
cases), the inner map will be freed by ops->map_free() in a kworker. But for now, most .map_free()
callbacks don't use synchronize_rcu() or its variants to wait for the elapse of a RCU grace period, so
after the invocation of ops->map_free completes, the bpf program which is accessing the inner map may
incur use-after-free problem. Fix the free of inner map by invoking bpf_map_free_deferred() after both one
RCU grace period and one tasks trace RCU grace period if the inner map has been removed from the outer map
before. The deferment is accomplished by using call_rcu() or call_rcu_tasks_trace() when releasing the
last ref-counter of bpf map. The newly-added rcu_head field in bpf_map shares the same storage space with
work field to reduce the size of bpf_map. (CVE-2023-52447)
- In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix kernel NULL pointer
dereference in gfs2_rgrp_dump Syzkaller has reported a NULL pointer dereference when accessing rgd->rd_rgl
in gfs2_rgrp_dump(). This can happen when creating rgd->rd_gl fails in read_rindex_entry(). Add a NULL
pointer check in gfs2_rgrp_dump() to prevent that. (CVE-2023-52448)
- In the Linux kernel, the following vulnerability has been resolved: mtd: Fix gluebi NULL pointer
dereference caused by ftl notifier If both ftl.ko and gluebi.ko are loaded, the notifier of ftl triggers
NULL pointer dereference when trying to access gluebi->desc' in gluebi_read(). ubi_gluebi_init
ubi_register_volume_notifier ubi_enumerate_volumes ubi_notify_all gluebi_notify nb->notifier_call()
gluebi_create mtd_device_register mtd_device_parse_register add_mtd_device blktrans_notify_add not->add()
ftl_add_mtd tr->add_mtd() scan_header mtd_read mtd_read_oob mtd_read_oob_std gluebi_read mtd->read()
gluebi->desc - NULL Detailed reproduction information available at the Link [1], In the normal case,
obtain gluebi->desc in the gluebi_get_device(), and access gluebi->desc in the gluebi_read(). However,
gluebi_get_device() is not executed in advance in the ftl_add_mtd() process, which leads to NULL pointer
dereference. The solution for the gluebi module is to run jffs2 on the UBI volume without considering
working with ftl or mtdblock [2]. Therefore, this problem can be avoided by preventing gluebi from
creating the mtdblock device after creating mtd partition of the type MTD_UBIVOLUME. (CVE-2023-52449)
- In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/memhp: Fix access
beyond end of drmem array dlpar_memory_remove_by_index() may access beyond the bounds of the drmem lmb
array when the LMB lookup fails to match an entry with the given DRC index. When the search fails, the
cursor is left pointing to &drmem_info->lmbs[drmem_info->n_lmbs], which is one element past the last valid
entry in the array. The debug message at the end of the function then dereferences this pointer:
pr_debug(Failed to hot-remove memory at %llx\n, lmb->base_addr); This was found by inspection and
confirmed with KASAN: pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234
================================================================== BUG: KASAN: slab-out-of-bounds in
dlpar_memory+0x298/0x1658 Read of size 8 at addr c000000364e97fd0 by task bash/949
dump_stack_lvl+0xa4/0xfc (unreliable) print_report+0x214/0x63c kasan_report+0x140/0x2e0
__asan_load8+0xa8/0xe0 dlpar_memory+0x298/0x1658 handle_dlpar_errorlog+0x130/0x1d0 dlpar_store+0x18c/0x3e0
kobj_attr_store+0x68/0xa0 sysfs_kf_write+0xc4/0x110 kernfs_fop_write_iter+0x26c/0x390
vfs_write+0x2d4/0x4e0 ksys_write+0xac/0x1a0 system_call_exception+0x268/0x530
system_call_vectored_common+0x15c/0x2ec Allocated by task 1: kasan_save_stack+0x48/0x80
kasan_set_track+0x34/0x50 kasan_save_alloc_info+0x34/0x50 __kasan_kmalloc+0xd0/0x120 __kmalloc+0x8c/0x320
kmalloc_array.constprop.0+0x48/0x5c drmem_init+0x2a0/0x41c do_one_initcall+0xe0/0x5c0
kernel_init_freeable+0x4ec/0x5a0 kernel_init+0x30/0x1e0 ret_from_kernel_user_thread+0x14/0x1c The buggy
address belongs to the object at c000000364e80000 which belongs to the cache kmalloc-128k of size 131072
The buggy address is located 0 bytes to the right of allocated 98256-byte region [c000000364e80000,
c000000364e97fd0) ================================================================== pseries-hotplug-mem:
Failed to hot-remove memory at 0 Log failed lookups with a separate message and dereference the cursor
only when it points to a valid entry. (CVE-2023-52451)
- In the Linux kernel, the following vulnerability has been resolved: bpf: Fix accesses to uninit stack
slots Privileged programs are supposed to be able to read uninitialized stack memory (ever since
6715df8d5) but, before this patch, these accesses were permitted inconsistently. In particular, accesses
were permitted above state->allocated_stack, but not below it. In other words, if the stack was already
large enough, the access was permitted, but otherwise the access was rejected instead of being allowed
to grow the stack. This undesired rejection was happening in two places: - in
check_stack_slot_within_bounds() - in check_stack_range_initialized() This patch arranges for these
accesses to be permitted. A bunch of tests that were relying on the old rejection had to change; all of
them were changed to add also run unprivileged, in which case the old behavior persists. One tests
couldn't be updated - global_func16 - because it can't run unprivileged for other reasons. This patch also
fixes the tracking of the stack size for variable-offset reads. This second fix is bundled in the same
commit as the first one because they're inter-related. Before this patch, writes to the stack using
registers containing a variable offset (as opposed to registers with fixed, known values) were not
properly contributing to the function's needed stack size. As a result, it was possible for a program to
verify, but then to attempt to read out-of-bounds data at runtime because a too small stack had been
allocated for it. Each function tracks the size of the stack it needs in bpf_subprog_info.stack_depth,
which is maintained by update_stack_depth(). For regular memory accesses, check_mem_access() was calling
update_state_depth() but it was passing in only the fixed part of the offset register, ignoring the
variable offset. This was incorrect; the minimum possible value of that register should be used instead.
This tracking is now fixed by centralizing the tracking of stack size in grow_stack_state(), and by
lifting the calls to grow_stack_state() to check_stack_access_within_bounds() as suggested by Andrii. The
code is now simpler and more convincingly tracks the correct maximum stack size.
check_stack_range_initialized() can now rely on enough stack having been allocated for the access; this
helps with the fix for the first issue. A few tests were changed to also check the stack depth
computation. The one that fails without this patch is verifier_var_off:stack_write_priv_vs_unpriv.
(CVE-2023-52452)
- In the Linux kernel, the following vulnerability has been resolved: serial: imx: fix tx statemachine
deadlock When using the serial port as RS485 port, the tx statemachine is used to control the RTS pin to
drive the RS485 transceiver TX_EN pin. When the TTY port is closed in the middle of a transmission (for
instance during userland application crash), imx_uart_shutdown disables the interface and disables the
Transmission Complete interrupt. afer that, imx_uart_stop_tx bails on an incomplete transmission, to be
retriggered by the TC interrupt. This interrupt is disabled and therefore the tx statemachine never
transitions out of SEND. The statemachine is in deadlock now, and the TX_EN remains low, making the
interface useless. imx_uart_stop_tx now checks for incomplete transmission AND whether TC interrupts are
enabled before bailing to be retriggered. This makes sure the state machine handling is reached, and is
properly set to WAIT_AFTER_SEND. (CVE-2023-52456)
- In the Linux kernel, the following vulnerability has been resolved: serial: 8250: omap: Don't skip
resource freeing if pm_runtime_resume_and_get() failed Returning an error code from .remove() makes the
driver core emit the little helpful error message: remove callback returned a non-zero value. This will be
ignored. and then remove the device anyhow. So all resources that were not freed are leaked in this case.
Skipping serial8250_unregister_port() has the potential to keep enough of the UART around to trigger a
use-after-free. So replace the error return (and with it the little helpful error message) by a more
useful error message and continue to cleanup. (CVE-2023-52457)
- In the Linux kernel, the following vulnerability has been resolved: efivarfs: force RO when remounting if
SetVariable is not supported If SetVariable at runtime is not supported by the firmware we never assign a
callback for that function. At the same time mount the efivarfs as RO so no one can call that. However, we
never check the permission flags when someone remounts the filesystem as RW. As a result this leads to a
crash looking like this: $ mount -o remount,rw /sys/firmware/efi/efivars $ efi-updatevar -f PK.auth PK [
303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [
303.280482] Mem abort info: [ 303.280854] ESR = 0x0000000086000004 [ 303.281338] EC = 0x21: IABT (current
EL), IL = 32 bits [ 303.282016] SET = 0, FnV = 0 [ 303.282414] EA = 0, S1PTW = 0 [ 303.282821] FSC = 0x04:
level 0 translation fault [ 303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000 [
303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 303.286076] Internal error:
Oops: 0000000086000004 [#1] PREEMPT SMP [ 303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core
crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6 [ 303.288586] CPU: 1 PID: 755 Comm:
efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1 [ 303.289748] Hardware name: Unknown Unknown
Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023 [ 303.291150] pstate: 60400005 (nZCv
daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 303.292123] pc : 0x0 [ 303.292443] lr :
efivar_set_variable_locked+0x74/0xec [ 303.293156] sp : ffff800008673c10 [ 303.293619] x29:
ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000 [ 303.294592] x26: 0000000000000800 x25:
ffff000002467400 x24: 0000000000000027 [ 303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21:
ffff000002467000 [ 303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000 [
303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54 [ 303.298495] x14:
ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4 [ 303.299453] x11: ffff000002af7b01 x10:
0000000000000003 x9 : 0000000000000002 [ 303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 :
0000000000a85201 [ 303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc [
303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000 [ 303.303341] Call trace: [
303.303679] 0x0 [ 303.303938] efivar_entry_set_get_size+0x98/0x16c [ 303.304585]
efivarfs_file_write+0xd0/0x1a4 [ 303.305148] vfs_write+0xc4/0x2e4 [ 303.305601] ksys_write+0x70/0x104 [
303.306073] __arm64_sys_write+0x1c/0x28 [ 303.306622] invoke_syscall+0x48/0x114 [ 303.307156]
el0_svc_common.constprop.0+0x44/0xec [ 303.307803] do_el0_svc+0x38/0x98 [ 303.308268] el0_svc+0x2c/0x84 [
303.308702] el0t_64_sync_handler+0xf4/0x120 [ 303.309293] el0t_64_sync+0x190/0x194 [ 303.309794] Code:
???????? ???????? ???????? ???????? (????????) [ 303.310612] ---[ end trace 0000000000000000 ]--- Fix this
by adding a .reconfigure() function to the fs operations which we can use to check the requested flags and
deny anything that's not RO if the firmware doesn't implement SetVariable at runtime. (CVE-2023-52463)
- In the Linux kernel, the following vulnerability has been resolved: EDAC/thunderx: Fix possible out-of-
bounds string access Enabling -Wstringop-overflow globally exposes a warning for a common bug in the usage
of strncat(): drivers/edac/thunderx_edac.c: In function 'thunderx_ocx_com_threaded_isr':
drivers/edac/thunderx_edac.c:1136:17: error: 'strncat' specified bound 1024 equals destination size
[-Werror=stringop-overflow=] 1136 | strncat(msg, other, OCX_MESSAGE_SIZE); |
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... 1145 | strncat(msg, other, OCX_MESSAGE_SIZE); ... 1150 |
strncat(msg, other, OCX_MESSAGE_SIZE); ... Apparently the author of this driver expected strncat() to
behave the way that strlcat() does, which uses the size of the destination buffer as its third argument
rather than the length of the source buffer. The result is that there is no check on the size of the
allocated buffer. Change it to strlcat(). [ bp: Trim compiler output, fixup commit message. ]
(CVE-2023-52464)
- In the Linux kernel, the following vulnerability has been resolved: 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)
- A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to
achieve local privilege escalation. The function nft_pipapo_walk did not skip inactive elements during set
walk which could lead double deactivations of PIPAPO (Pile Packet Policies) elements, leading to use-
after-free. We recommend upgrading past commit 317eb9685095678f2c9f5a8189de698c5354316a. (CVE-2023-6817)
- 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)
- 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)
- 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 before 6.6.7, an untrusted VMM can trigger int80 syscall handling at any given point.
This is related to arch/x86/coco/tdx/tdx.c and arch/x86/mm/mem_encrypt_amd.c. (CVE-2024-25744)
- 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 stack
corruption When tc filters are first added to a net device, the corresponding local port gets bound to an
ACL group in the device. The group contains a list of ACLs. In turn, each ACL points to a different TCAM
region where the filters are stored. During forwarding, the ACLs are sequentially evaluated until a match
is found. One reason to place filters in different regions is when they are added with decreasing
priorities and in an alternating order so that two consecutive filters can never fit in the same region
because of their key usage. In Spectrum-2 and newer ASICs the firmware started to report that the maximum
number of ACLs in a group is more than 16, but the layout of the register that configures ACL groups
(PAGT) was not updated to account for that. It is therefore possible to hit stack corruption [1] in the
rare case where more than 16 ACLs in a group are required. Fix by limiting the maximum ACL group size to
the minimum between what the firmware reports and the maximum ACLs that fit in the PAGT register. Add a
test case to make sure the machine does not crash when this condition is hit. [1] Kernel panic - not
syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120 [...]
dump_stack_lvl+0x36/0x50 panic+0x305/0x330 __stack_chk_fail+0x15/0x20
mlxsw_sp_acl_tcam_group_update+0x116/0x120 mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110
mlxsw_sp_acl_tcam_vchunk_get+0x492/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-26586)
- In the Linux kernel, the following vulnerability has been resolved: bpf: Reject variable offset alu on
PTR_TO_FLOW_KEYS For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off for validation.
However, variable offset ptr alu is not prohibited for this ptr kind. So the variable offset is not
checked. The following prog is accepted: func#0 @0 0: R1=ctx() R10=fp0 0: (bf) r6 = r1 ; R1=ctx()
R6_w=ctx() 1: (79) r7 = *(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flow_keys() 2: (b7) r8 = 1024 ; R8_w=1024 3:
(37) r8 /= 1 ; R8_w=scalar() 4: (57) r8 &= 1024 ; R8_w=scalar(smin=smin32=0,
smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400)) 5: (0f) r7 += r8 mark_precise: frame0: last_idx 5
first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &= 1024 mark_precise:
frame0: regs=r8 stack= before 3: (37) r8 /= 1 mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 =
1024 6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off =(0x0; 0x400))
R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024, var_off=(0x0; 0x400)) 6: (79) r0 = *(u64 *)(r7 +0)
; R0_w=scalar() 7: (95) exit This prog loads flow_keys to r7, and adds the variable offset r8 to r7, and
finally causes out-of-bounds access: BUG: unable to handle page fault for address: ffffc90014c80038 [...]
Call Trace: <TASK> bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline] __bpf_prog_run
include/linux/filter.h:651 [inline] bpf_prog_run include/linux/filter.h:658 [inline]
bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline] bpf_flow_dissect+0x15f/0x350
net/core/flow_dissector.c:991 bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359
bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline] __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475
__do_sys_bpf kernel/bpf/syscall.c:5561 [inline] __se_sys_bpf kernel/bpf/syscall.c:5559 [inline]
__x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Fix this by
rejecting ptr alu with variable offset on flow_keys. Applying the patch rejects the program with R7
pointer arithmetic on flow_keys prohibited. (CVE-2024-26589)
- In the Linux kernel, the following vulnerability has been resolved: bpf: Fix re-attachment branch in
bpf_tracing_prog_attach The following case can cause a crash due to missing attach_btf: 1) load rawtp
program 2) load fentry program with rawtp as target_fd 3) create tracing link for fentry program with
target_fd = 0 4) repeat 3 In the end we have: - prog->aux->dst_trampoline == NULL - tgt_prog == NULL
(because we did not provide target_fd to link_create) - prog->aux->attach_btf == NULL (the program was
loaded with attach_prog_fd=X) - the program was loaded for tgt_prog but we have no way to find out which
one BUG: kernel NULL pointer dereference, address: 0000000000000058 Call Trace: <TASK> ? __die+0x20/0x70 ?
page_fault_oops+0x15b/0x430 ? fixup_exception+0x22/0x330 ? exc_page_fault+0x6f/0x170 ?
asm_exc_page_fault+0x22/0x30 ? bpf_tracing_prog_attach+0x279/0x560 ? btf_obj_id+0x5/0x10
bpf_tracing_prog_attach+0x439/0x560 __sys_bpf+0x1cf4/0x2de0 __x64_sys_bpf+0x1c/0x30
do_syscall_64+0x41/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Return -EINVAL in this situation.
(CVE-2024-26591)
- In the Linux kernel, the following vulnerability has been resolved: i2c: i801: Fix block process call
transactions According to the Intel datasheets, software must reset the block buffer index twice for block
process call transactions: once before writing the outgoing data to the buffer, and once again before
reading the incoming data from the buffer. The driver is currently missing the second reset, causing the
wrong portion of the block buffer to be read. (CVE-2024-26593)
- 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: KVM: arm64: vgic-its: Avoid potential
UAF in LPI translation cache There is a potential UAF scenario in the case of an LPI translation cache hit
racing with an operation that invalidates the cache, such as a DISCARD ITS command. The root of the
problem is that vgic_its_check_cache() does not elevate the refcount on the vgic_irq before dropping the
lock that serializes refcount changes. Have vgic_its_check_cache() raise the refcount on the returned
vgic_irq and add the corresponding decrement after queueing the interrupt. (CVE-2024-26598)
- In the Linux kernel, the following vulnerability has been resolved: 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: x86/fpu: Stop relying on userspace for
info to fault in xsave buffer Before this change, the expected size of the user space buffer was taken
from fx_sw->xstate_size. fx_sw->xstate_size can be changed from user-space, so it is possible construct a
sigreturn frame where: * fx_sw->xstate_size is smaller than the size required by valid bits in
fx_sw->xfeatures. * user-space unmaps parts of the sigrame fpu buffer so that not all of the buffer
required by xrstor is accessible. In this case, xrstor tries to restore and accesses the unmapped area
which results in a fault. But fault_in_readable succeeds because buf + fx_sw->xstate_size is within the
still mapped area, so it goes back and tries xrstor again. It will spin in this loop forever. Instead,
fault in the maximum size which can be touched by XRSTOR (taken from fpstate->user_size). [ dhansen: tweak
subject / changelog ] (CVE-2024-26603)
- 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/1194869");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1206453");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1209412");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1213456");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1216776");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1217927");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1218195");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1218216");
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/1218663");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1218915");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1219126");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1219127");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1219141");
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/1219443");
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/1219839");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1219840");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1219934");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220003");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220009");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220021");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220030");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220106");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220140");
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/1220243");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220250");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220251");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220253");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220254");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220255");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220257");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220267");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220277");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220317");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220326");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220328");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220330");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220335");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220344");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220348");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220350");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220364");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220392");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220393");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220398");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220409");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220444");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220457");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220459");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220649");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220796");
script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220825");
# https://lists.suse.com/pipermail/sle-security-updates/2024-March/018153.html
script_set_attribute(attribute:"see_also", value:"http://www.nessus.org/u?604c6725");
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-2021-46923");
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-46932");
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-5197");
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-52439");
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-52447");
script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52448");
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-52452");
script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52456");
script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52457");
script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52463");
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-6817");
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-23850");
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-25744");
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-26586");
script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26589");
script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26591");
script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26593");
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-26598");
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-26603");
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-2024-26598");
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:"2023/09/27");
script_set_attribute(attribute:"patch_publication_date", value:"2024/03/13");
script_set_attribute(attribute:"plugin_publication_date", value:"2024/03/13");
script_set_attribute(attribute:"plugin_type", value:"local");
script_set_attribute(attribute:"cpe", value:"cpe:/o:novell:suse_linux:15");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:cluster-md-kmp-default");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:dlm-kmp-default");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:gfs2-kmp-default");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-64kb");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-64kb-devel");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-default");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-default-base");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-default-devel");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-default-extra");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-default-livepatch");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-default-livepatch-devel");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-devel");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-livepatch-5_14_21-150500_55_52-default");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-macros");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-obs-build");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-source");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-syms");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-zfcpdump");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:ocfs2-kmp-default");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:reiserfs-kmp-default");
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:"^(SLED15|SLED_SAP15|SLES15|SLES_SAP15|SUSE15\.5)$", string:os_ver)) audit(AUDIT_OS_NOT, 'SUSE SLED15 / SLED_SAP15 / 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 == "SLED15" && (! preg(pattern:"^(5)$", string:service_pack))) audit(AUDIT_OS_NOT, "SLED15 SP5", os_ver + " SP" + service_pack);
if (os_ver == "SLED_SAP15" && (! preg(pattern:"^(5)$", string:service_pack))) audit(AUDIT_OS_NOT, "SLED_SAP15 SP5", os_ver + " SP" + service_pack);
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-64kb-5.14.21-150500.55.52.1', 'sp':'5', 'cpu':'aarch64', 'release':'SLED_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
{'reference':'kernel-64kb-5.14.21-150500.55.52.1', 'sp':'5', 'cpu':'aarch64', 'release':'SLES_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
{'reference':'kernel-64kb-devel-5.14.21-150500.55.52.1', 'sp':'5', 'cpu':'aarch64', 'release':'SLED_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
{'reference':'kernel-64kb-devel-5.14.21-150500.55.52.1', 'sp':'5', 'cpu':'aarch64', 'release':'SLES_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
{'reference':'kernel-default-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLED_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
{'reference':'kernel-default-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLES_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
{'reference':'kernel-default-base-5.14.21-150500.55.52.1.150500.6.23.1', 'sp':'5', 'cpu':'aarch64', 'release':'SLED_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
{'reference':'kernel-default-base-5.14.21-150500.55.52.1.150500.6.23.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLED_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
{'reference':'kernel-default-base-5.14.21-150500.55.52.1.150500.6.23.1', 'sp':'5', 'cpu':'aarch64', 'release':'SLES_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
{'reference':'kernel-default-base-5.14.21-150500.55.52.1.150500.6.23.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLES_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
{'reference':'kernel-default-devel-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLED_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
{'reference':'kernel-default-devel-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLES_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
{'reference':'kernel-default-extra-5.14.21-150500.55.52.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLED_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
{'reference':'kernel-default-extra-5.14.21-150500.55.52.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLES_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
{'reference':'kernel-devel-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLED_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
{'reference':'kernel-devel-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLES_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
{'reference':'kernel-macros-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLED_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
{'reference':'kernel-macros-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLES_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
{'reference':'kernel-obs-build-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLED_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
{'reference':'kernel-obs-build-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLES_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
{'reference':'kernel-source-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLED_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
{'reference':'kernel-source-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLES_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
{'reference':'kernel-syms-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLED_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
{'reference':'kernel-syms-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLES_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
{'reference':'kernel-zfcpdump-5.14.21-150500.55.52.1', 'sp':'5', 'cpu':'s390x', 'release':'SLED_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
{'reference':'kernel-zfcpdump-5.14.21-150500.55.52.1', 'sp':'5', 'cpu':'s390x', 'release':'SLES_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
{'reference':'reiserfs-kmp-default-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLES_SAP15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-15.5']},
{'reference':'kernel-64kb-5.14.21-150500.55.52.1', 'sp':'5', 'cpu':'aarch64', 'release':'SLED15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-basesystem-release-15.5', 'sled-release-15.5', 'sles-release-15.5']},
{'reference':'kernel-64kb-5.14.21-150500.55.52.1', 'sp':'5', 'cpu':'aarch64', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-basesystem-release-15.5', 'sled-release-15.5', 'sles-release-15.5']},
{'reference':'kernel-64kb-devel-5.14.21-150500.55.52.1', 'sp':'5', 'cpu':'aarch64', 'release':'SLED15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-basesystem-release-15.5', 'sled-release-15.5', 'sles-release-15.5']},
{'reference':'kernel-64kb-devel-5.14.21-150500.55.52.1', 'sp':'5', 'cpu':'aarch64', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-basesystem-release-15.5', 'sled-release-15.5', 'sles-release-15.5']},
{'reference':'kernel-default-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLED15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-basesystem-release-15.5', 'sled-release-15.5', 'sles-release-15.5']},
{'reference':'kernel-default-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-basesystem-release-15.5', 'sled-release-15.5', 'sles-release-15.5']},
{'reference':'kernel-default-base-5.14.21-150500.55.52.1.150500.6.23.1', 'sp':'5', 'cpu':'aarch64', 'release':'SLED15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-basesystem-release-15.5', 'sled-release-15.5', 'sles-release-15.5']},
{'reference':'kernel-default-base-5.14.21-150500.55.52.1.150500.6.23.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLED15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-basesystem-release-15.5', 'sled-release-15.5', 'sles-release-15.5']},
{'reference':'kernel-default-base-5.14.21-150500.55.52.1.150500.6.23.1', 'sp':'5', 'cpu':'aarch64', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-basesystem-release-15.5', 'sled-release-15.5', 'sles-release-15.5']},
{'reference':'kernel-default-base-5.14.21-150500.55.52.1.150500.6.23.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-basesystem-release-15.5', 'sled-release-15.5', 'sles-release-15.5']},
{'reference':'kernel-default-devel-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLED15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-basesystem-release-15.5', 'sled-release-15.5', 'sles-release-15.5']},
{'reference':'kernel-default-devel-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-basesystem-release-15.5', 'sled-release-15.5', 'sles-release-15.5']},
{'reference':'kernel-devel-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLED15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-basesystem-release-15.5', 'sled-release-15.5', 'sles-release-15.5']},
{'reference':'kernel-devel-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-basesystem-release-15.5', 'sled-release-15.5', 'sles-release-15.5']},
{'reference':'kernel-macros-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLED15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-basesystem-release-15.5', 'sled-release-15.5', 'sles-release-15.5']},
{'reference':'kernel-macros-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-basesystem-release-15.5', 'sled-release-15.5', 'sles-release-15.5']},
{'reference':'kernel-obs-build-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLED15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-development-tools-release-15.5', 'sled-release-15.5', 'sles-release-15.5']},
{'reference':'kernel-obs-build-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-development-tools-release-15.5', 'sled-release-15.5', 'sles-release-15.5']},
{'reference':'kernel-source-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLED15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-development-tools-release-15.5', 'sled-release-15.5', 'sles-release-15.5']},
{'reference':'kernel-source-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-development-tools-release-15.5', 'sled-release-15.5', 'sles-release-15.5']},
{'reference':'kernel-syms-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLED15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-development-tools-release-15.5', 'sled-release-15.5', 'sles-release-15.5']},
{'reference':'kernel-syms-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-development-tools-release-15.5', 'sled-release-15.5', 'sles-release-15.5']},
{'reference':'kernel-zfcpdump-5.14.21-150500.55.52.1', 'sp':'5', 'cpu':'s390x', 'release':'SLED15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-basesystem-release-15.5', 'sled-release-15.5', 'sles-release-15.5']},
{'reference':'kernel-zfcpdump-5.14.21-150500.55.52.1', 'sp':'5', 'cpu':'s390x', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-basesystem-release-15.5', 'sled-release-15.5', 'sles-release-15.5']},
{'reference':'reiserfs-kmp-default-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLE_HPC-release-15.5', 'sle-module-legacy-release-15.5', 'sles-release-15.5']},
{'reference':'cluster-md-kmp-64kb-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'cluster-md-kmp-default-5.14.21-150500.55.52.1', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'dlm-kmp-64kb-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'dlm-kmp-default-5.14.21-150500.55.52.1', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'dtb-allwinner-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'dtb-altera-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'dtb-amazon-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'dtb-amd-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'dtb-amlogic-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'dtb-apm-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'dtb-apple-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'dtb-arm-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'dtb-broadcom-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'dtb-cavium-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'dtb-exynos-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'dtb-freescale-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'dtb-hisilicon-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'dtb-lg-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'dtb-marvell-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'dtb-mediatek-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'dtb-nvidia-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'dtb-qcom-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'dtb-renesas-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'dtb-rockchip-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'dtb-socionext-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'dtb-sprd-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'dtb-xilinx-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'gfs2-kmp-64kb-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'gfs2-kmp-default-5.14.21-150500.55.52.1', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-64kb-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-64kb-devel-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-64kb-extra-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-64kb-livepatch-devel-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-64kb-optional-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-debug-5.14.21-150500.55.52.1', 'cpu':'x86_64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-debug-devel-5.14.21-150500.55.52.1', 'cpu':'x86_64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-debug-livepatch-devel-5.14.21-150500.55.52.1', 'cpu':'x86_64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-debug-vdso-5.14.21-150500.55.52.1', 'cpu':'x86_64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-default-5.14.21-150500.55.52.1', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-default-base-5.14.21-150500.55.52.1.150500.6.23.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-default-base-5.14.21-150500.55.52.1.150500.6.23.1', 'cpu':'x86_64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-default-base-rebuild-5.14.21-150500.55.52.1.150500.6.23.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-default-base-rebuild-5.14.21-150500.55.52.1.150500.6.23.1', 'cpu':'x86_64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-default-devel-5.14.21-150500.55.52.1', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-default-extra-5.14.21-150500.55.52.1', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-default-livepatch-5.14.21-150500.55.52.1', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-default-livepatch-devel-5.14.21-150500.55.52.1', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-default-optional-5.14.21-150500.55.52.1', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-default-vdso-5.14.21-150500.55.52.1', 'cpu':'x86_64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-devel-5.14.21-150500.55.52.1', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-kvmsmall-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-kvmsmall-5.14.21-150500.55.52.1', 'cpu':'x86_64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-kvmsmall-devel-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-kvmsmall-devel-5.14.21-150500.55.52.1', 'cpu':'x86_64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-kvmsmall-livepatch-devel-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-kvmsmall-livepatch-devel-5.14.21-150500.55.52.1', 'cpu':'x86_64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-kvmsmall-vdso-5.14.21-150500.55.52.1', 'cpu':'x86_64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-macros-5.14.21-150500.55.52.1', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-obs-build-5.14.21-150500.55.52.1', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-obs-qa-5.14.21-150500.55.52.1', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-source-5.14.21-150500.55.52.1', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-source-vanilla-5.14.21-150500.55.52.1', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-syms-5.14.21-150500.55.52.1', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kernel-zfcpdump-5.14.21-150500.55.52.1', 'cpu':'s390x', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kselftests-kmp-64kb-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'kselftests-kmp-default-5.14.21-150500.55.52.1', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'ocfs2-kmp-64kb-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'ocfs2-kmp-default-5.14.21-150500.55.52.1', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'reiserfs-kmp-64kb-5.14.21-150500.55.52.1', 'cpu':'aarch64', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'reiserfs-kmp-default-5.14.21-150500.55.52.1', 'release':'SUSE15.5', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['openSUSE-release-15.5']},
{'reference':'cluster-md-kmp-default-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['sle-ha-release-15.5']},
{'reference':'dlm-kmp-default-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['sle-ha-release-15.5']},
{'reference':'gfs2-kmp-default-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['sle-ha-release-15.5']},
{'reference':'ocfs2-kmp-default-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['sle-ha-release-15.5']},
{'reference':'kernel-default-livepatch-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['sle-module-live-patching-release-15.5']},
{'reference':'kernel-default-livepatch-devel-5.14.21-150500.55.52.1', 'sp':'5', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['sle-module-live-patching-release-15.5']},
{'reference':'kernel-livepatch-5_14_21-150500_55_52-default-1-150500.11.3.1', 'sp':'5', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['sle-module-live-patching-release-15.5']},
{'reference':'kernel-default-extra-5.14.21-150500.55.52.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLED15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['sle-we-release-15.5', 'sled-release-15.5', 'sles-release-15.5']},
{'reference':'kernel-default-extra-5.14.21-150500.55.52.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLES15', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['sle-we-release-15.5', 'sled-release-15.5', 'sles-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-64kb / cluster-md-kmp-default / dlm-kmp-64kb / etc');
}
Vendor | Product | Version | CPE |
---|---|---|---|
novell | suse_linux | kernel-macros | p-cpe:/a:novell:suse_linux:kernel-macros |
novell | suse_linux | kernel-zfcpdump | p-cpe:/a:novell:suse_linux:kernel-zfcpdump |
novell | suse_linux | kernel-64kb-devel | p-cpe:/a:novell:suse_linux:kernel-64kb-devel |
novell | suse_linux | ocfs2-kmp-default | p-cpe:/a:novell:suse_linux:ocfs2-kmp-default |
novell | suse_linux | dlm-kmp-default | p-cpe:/a:novell:suse_linux:dlm-kmp-default |
novell | suse_linux | kernel-default-base | p-cpe:/a:novell:suse_linux:kernel-default-base |
novell | suse_linux | kernel-default-livepatch | p-cpe:/a:novell:suse_linux:kernel-default-livepatch |
novell | suse_linux | kernel-default-devel | p-cpe:/a:novell:suse_linux:kernel-default-devel |
novell | suse_linux | kernel-devel | p-cpe:/a:novell:suse_linux:kernel-devel |
novell | suse_linux | gfs2-kmp-default | p-cpe:/a:novell:suse_linux:gfs2-kmp-default |
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-25162
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-46923
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-46924
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-46932
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-28746
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-5197
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-52340
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-52429
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-52439
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-52443
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-52445
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-52447
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-52448
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-52449
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-52451
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-52452
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-52456
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-52457
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-52463
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-52464
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-52475
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-52478
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-6817
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-0607
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-1151
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-23849
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-23850
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-23851
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-25744
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-26585
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-26586
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-26589
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-26591
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-26593
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-26595
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-26598
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-26602
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-26603
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-26622
www.nessus.org/u?604c6725
bugzilla.suse.com/1194869
bugzilla.suse.com/1206453
bugzilla.suse.com/1209412
bugzilla.suse.com/1213456
bugzilla.suse.com/1216776
bugzilla.suse.com/1217927
bugzilla.suse.com/1218195
bugzilla.suse.com/1218216
bugzilla.suse.com/1218450
bugzilla.suse.com/1218527
bugzilla.suse.com/1218663
bugzilla.suse.com/1218915
bugzilla.suse.com/1219126
bugzilla.suse.com/1219127
bugzilla.suse.com/1219141
bugzilla.suse.com/1219146
bugzilla.suse.com/1219295
bugzilla.suse.com/1219443
bugzilla.suse.com/1219653
bugzilla.suse.com/1219827
bugzilla.suse.com/1219835
bugzilla.suse.com/1219839
bugzilla.suse.com/1219840
bugzilla.suse.com/1219934
bugzilla.suse.com/1220003
bugzilla.suse.com/1220009
bugzilla.suse.com/1220021
bugzilla.suse.com/1220030
bugzilla.suse.com/1220106
bugzilla.suse.com/1220140
bugzilla.suse.com/1220187
bugzilla.suse.com/1220238
bugzilla.suse.com/1220240
bugzilla.suse.com/1220241
bugzilla.suse.com/1220243
bugzilla.suse.com/1220250
bugzilla.suse.com/1220251
bugzilla.suse.com/1220253
bugzilla.suse.com/1220254
bugzilla.suse.com/1220255
bugzilla.suse.com/1220257
bugzilla.suse.com/1220267
bugzilla.suse.com/1220277
bugzilla.suse.com/1220317
bugzilla.suse.com/1220326
bugzilla.suse.com/1220328
bugzilla.suse.com/1220330
bugzilla.suse.com/1220335
bugzilla.suse.com/1220344
bugzilla.suse.com/1220348
bugzilla.suse.com/1220350
bugzilla.suse.com/1220364
bugzilla.suse.com/1220392
bugzilla.suse.com/1220393
bugzilla.suse.com/1220398
bugzilla.suse.com/1220409
bugzilla.suse.com/1220444
bugzilla.suse.com/1220457
bugzilla.suse.com/1220459
bugzilla.suse.com/1220649
bugzilla.suse.com/1220796
bugzilla.suse.com/1220825
www.suse.com/security/cve/CVE-2019-25162
www.suse.com/security/cve/CVE-2021-46923
www.suse.com/security/cve/CVE-2021-46924
www.suse.com/security/cve/CVE-2021-46932
www.suse.com/security/cve/CVE-2023-28746
www.suse.com/security/cve/CVE-2023-5197
www.suse.com/security/cve/CVE-2023-52340
www.suse.com/security/cve/CVE-2023-52429
www.suse.com/security/cve/CVE-2023-52439
www.suse.com/security/cve/CVE-2023-52443
www.suse.com/security/cve/CVE-2023-52445
www.suse.com/security/cve/CVE-2023-52447
www.suse.com/security/cve/CVE-2023-52448
www.suse.com/security/cve/CVE-2023-52449
www.suse.com/security/cve/CVE-2023-52451
www.suse.com/security/cve/CVE-2023-52452
www.suse.com/security/cve/CVE-2023-52456
www.suse.com/security/cve/CVE-2023-52457
www.suse.com/security/cve/CVE-2023-52463
www.suse.com/security/cve/CVE-2023-52464
www.suse.com/security/cve/CVE-2023-52475
www.suse.com/security/cve/CVE-2023-52478
www.suse.com/security/cve/CVE-2023-6817
www.suse.com/security/cve/CVE-2024-0607
www.suse.com/security/cve/CVE-2024-1151
www.suse.com/security/cve/CVE-2024-23849
www.suse.com/security/cve/CVE-2024-23850
www.suse.com/security/cve/CVE-2024-23851
www.suse.com/security/cve/CVE-2024-25744
www.suse.com/security/cve/CVE-2024-26585
www.suse.com/security/cve/CVE-2024-26586
www.suse.com/security/cve/CVE-2024-26589
www.suse.com/security/cve/CVE-2024-26591
www.suse.com/security/cve/CVE-2024-26593
www.suse.com/security/cve/CVE-2024-26595
www.suse.com/security/cve/CVE-2024-26598
www.suse.com/security/cve/CVE-2024-26602
www.suse.com/security/cve/CVE-2024-26603
www.suse.com/security/cve/CVE-2024-26622
7.8 High
CVSS3
Attack Vector
LOCAL
Attack Complexity
LOW
Privileges Required
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
HIGH
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
7.8 High
AI Score
Confidence
High
0.0004 Low
EPSS
Percentile
10.5%