In the Linux kernel, the following vulnerability has been resolved: drm/gud: Fix UBSAN warning UBSAN complains about invalid value for bool: [ 101.165172] [drm] Initialized gud 1.0.0 20200422 for 2-3.2:1.0 on minor 1 [ 101.213360] gud 2-3.2:1.0: [drm] fb1: guddrmfb frame buffer device [ 101.213426] usbcore: registered new interface driver gud [ 101.989431] ================================================================================ [ 101.989441] UBSAN: invalid-load in linux/include/linux/iosys-map.h:253:9 [ 101.989447] load of value 121 is not a valid value for type '_Bool' [ 101.989451] CPU: 1 PID: 455 Comm: kworker/1:6 Not tainted 5.18.0-rc5-gud-5.18-rc5 #3 [ 101.989456] Hardware name: Hewlett-Packard HP EliteBook 820 G1/1991, BIOS L71 Ver. 01.44 04/12/2018 [ 101.989459] Workqueue: events_long gud_flush_work [gud] [ 101.989471] Call Trace: [ 101.989474] <TASK> [ 101.989479] dump_stack_lvl+0x49/0x5f [ 101.989488] dump_stack+0x10/0x12 [ 101.989493] ubsan_epilogue+0x9/0x3b [ 101.989498] __ubsan_handle_load_invalid_value.cold+0x44/0x49 [ 101.989504] dma_buf_vmap.cold+0x38/0x3d [ 101.989511] ? find_busiest_group+0x48/0x300 [ 101.989520] drm_gem_shmem_vmap+0x76/0x1b0 [drm_shmem_helper] [ 101.989528] drm_gem_shmem_object_vmap+0x9/0xb [drm_shmem_helper] [ 101.989535] drm_gem_vmap+0x26/0x60 [drm] [ 101.989594] drm_gem_fb_vmap+0x47/0x150 [drm_kms_helper] [ 101.989630] gud_prep_flush+0xc1/0x710 [gud] [ 101.989639] ? _raw_spin_lock+0x17/0x40 [ 101.989648] gud_flush_work+0x1e0/0x430 [gud] [ 101.989653] ? __switch_to+0x11d/0x470 [ 101.989664] process_one_work+0x21f/0x3f0 [ 101.989673] worker_thread+0x200/0x3e0 [ 101.989679] ? rescuer_thread+0x390/0x390 [ 101.989684] kthread+0xfd/0x130 [ 101.989690] ? kthread_complete_and_exit+0x20/0x20 [ 101.989696] ret_from_fork+0x22/0x30 [ 101.989706] </TASK> [ 101.989708] ================================================================================ The source of this warning is in iosys_map_clear() called from dma_buf_vmap(). It conditionally sets values based on map->is_iomem. The iosys_map variables are allocated uninitialized on the stack leading to ->is_iomem having all kinds of values and not only 0/1. Fix this by zeroing the iosys_map variables.

The AlmaLinux 9.2 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.2:CLSA-2026:1786350974 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: isofs: Fix out of bound access for     corrupted isofs image When isofs image is suitably corrupted isofs_read_inode() can read data beyond the     end of buffer. Sanity-check the directory entry length before using it. (CVE-2021-47478)

  - In the Linux kernel, the following vulnerability has been resolved: ubi: Fix race condition between     ctrl_cdev_ioctl and ubi_cdev_ioctl Hulk Robot reported a KASAN report about use-after-free:
    ================================================================== BUG: KASAN: use-after-free in
    __list_del_entry_valid+0x13d/0x160 Read of size 8 at addr ffff888035e37d98 by task ubiattach/1385 [...]     Call Trace: klist_dec_and_del+0xa7/0x4a0 klist_put+0xc7/0x1a0 device_del+0x4d4/0xed0     cdev_device_del+0x1a/0x80 ubi_attach_mtd_dev+0x2951/0x34b0 [ubi] ctrl_cdev_ioctl+0x286/0x2f0 [ubi]     Allocated by task 1414: device_add+0x60a/0x18b0 cdev_device_add+0x103/0x170     ubi_create_volume+0x1118/0x1a10 [ubi] ubi_cdev_ioctl+0xb7f/0x1ba0 [ubi] Freed by task 1385:
    cdev_device_del+0x1a/0x80 ubi_remove_volume+0x438/0x6c0 [ubi] ubi_cdev_ioctl+0xbf4/0x1ba0 [ubi] [...]     ================================================================== The lock held by ctrl_cdev_ioctl is     ubi_devices_mutex, but the lock held by ubi_cdev_ioctl is ubi->device_mutex. Therefore, the two locks can     be concurrent. ctrl_cdev_ioctl contains two operations: ubi_attach and ubi_detach. ubi_detach is bug-free     because it uses reference counting to prevent concurrency. However, uif_init and uif_close in ubi_attach     may race with ubi_cdev_ioctl. uif_init will race with ubi_cdev_ioctl as in the following stack. cpu1 cpu2     cpu3 _______________________|________________________|______________________ ctrl_cdev_ioctl     ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_add_volume // sysfs exist     kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // first free ubi_free_volume cdev_del //     double free cdev_device_del And uif_close will race with ubi_cdev_ioctl as in the following stack. cpu1     cpu2 cpu3 _______________________|________________________|______________________ ctrl_cdev_ioctl     ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_debugfs_init_dev //error     goto out_uif; uif_close kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // first free     ubi_free_volume // double free The cause of this problem is that commit 714fb87e8bc0 make device     available before it becomes accessible via sysfs. Therefore, we roll back the modification. We will fix     the race condition between ubi device creation and udev by removing ubi_get_device in vol_attribute_show     and dev_attribute_show.This avoids accessing uninitialized ubi_devices[ubi_num]. ubi_get_device is used to     prevent devices from being deleted during sysfs execution. However, now kernfs ensures that devices will     not be deleted before all reference counting are released. The key process is shown in the following     stack. device_del device_remove_attrs device_remove_groups sysfs_remove_groups sysfs_remove_group     remove_files kernfs_remove_by_name kernfs_remove_by_name_ns __kernfs_remove kernfs_drain (CVE-2021-47634)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix memory leak in
    __qlt_24xx_handle_abts() Commit 8f394da36a36 (scsi: qla2xxx: Drop TARGET_SCF_LOOKUP_LUN_FROM_TAG) made     the __qlt_24xx_handle_abts() function return early if tcm_qla2xxx_find_cmd_by_tag() didn't find a command,     but it missed to clean up the allocated memory for the management command. (CVE-2022-48650)

  - In the Linux kernel, the following vulnerability has been resolved: ubi: ubi_create_volume: Fix use-after-     free when volume creation failed There is an use-after-free problem for 'eba_tbl' in ubi_create_volume()'s     error handling path: ubi_eba_replace_table(vol, eba_tbl) vol->eba_tbl = tbl out_mapping:
    ubi_eba_destroy_table(eba_tbl) // Free 'eba_tbl' out_unlock: put_device(&vol->dev) vol_release     kfree(tbl->entries) // UAF Fix it by removing redundant 'eba_tbl' releasing. Fetch a reproducer in [Link].
    (CVE-2022-49388)

  - In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3: Fix error handling in     gic_populate_ppi_partitions of_get_child_by_name() returns a node pointer with refcount incremented, we     should use of_node_put() on it when not need anymore. When kcalloc fails, it missing of_node_put() and     results in refcount leak. Fix this by goto out_put_node label. (CVE-2022-49716)

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

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - drm/gud: Fix UBSAN warning UBSAN complains about invalid value for bool: [ 101.165172] [drm] Initialized     gud 1.0.0 20200422 for 2-3.2:1.0 on minor 1 [ 101.213360] gud 2-3.2:1.0: [drm] fb1: guddrmfb frame buffer     device [ 101.213426] usbcore: registered new interface driver gud [ 101.989431]     ================================================================================ [ 101.989441] UBSAN:
    invalid-load in linux/include/linux/iosys-map.h:253:9 [ 101.989447] load of value 121 is not a valid value     for type '_Bool' [ 101.989451] CPU: 1 PID: 455 Comm: kworker/1:6 Not tainted 5.18.0-rc5-gud-5.18-rc5 #3 [     101.989456] Hardware name: Hewlett-Packard HP EliteBook 820 G1/1991, BIOS L71 Ver. 01.44 04/12/2018 [     101.989459] Workqueue: events_long gud_flush_work [gud] [ 101.989471] Call Trace: [ 101.989474] <TASK> [     101.989479] dump_stack_lvl+0x49/0x5f [ 101.989488] dump_stack+0x10/0x12 [ 101.989493]     ubsan_epilogue+0x9/0x3b [ 101.989498] __ubsan_handle_load_invalid_value.cold+0x44/0x49 [ 101.989504]     dma_buf_vmap.cold+0x38/0x3d [ 101.989511] ? find_busiest_group+0x48/0x300 [ 101.989520]     drm_gem_shmem_vmap+0x76/0x1b0 [drm_shmem_helper] [ 101.989528] drm_gem_shmem_object_vmap+0x9/0xb     [drm_shmem_helper] [ 101.989535] drm_gem_vmap+0x26/0x60 [drm] [ 101.989594] drm_gem_fb_vmap+0x47/0x150     [drm_kms_helper] [ 101.989630] gud_prep_flush+0xc1/0x710 [gud] [ 101.989639] ? _raw_spin_lock+0x17/0x40 [     101.989648] gud_flush_work+0x1e0/0x430 [gud] [ 101.989653] ? __switch_to+0x11d/0x470 [ 101.989664]     process_one_work+0x21f/0x3f0 [ 101.989673] worker_thread+0x200/0x3e0 [ 101.989679] ?     rescuer_thread+0x390/0x390 [ 101.989684] kthread+0xfd/0x130 [ 101.989690] ?     kthread_complete_and_exit+0x20/0x20 [ 101.989696] ret_from_fork+0x22/0x30 [ 101.989706] </TASK> [     101.989708] ================================================================================ The source of     this warning is in iosys_map_clear() called from dma_buf_vmap(). It conditionally sets values based on     map->is_iomem. The iosys_map variables are allocated uninitialized on the stack leading to ->is_iomem     having all kinds of values and not only 0/1. Fix this by zeroing the iosys_map variables. (CVE-2022-50628)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
360716	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1786350974)	Nessus	Alma Linux Local Security Checks	Local	high
277773	Linux Distros Unpatched Vulnerability : CVE-2022-50628	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2022-50628

low

Tenable Plugins

high

high