Linux Kernel vulnerabilities

CVE-2022-50319 [MEDIUM] CVE-2022-50319: In the Linux kernel, the following vulnerability has been resolved: coresight: trbe: remove cpuhp i In the Linux kernel, the following vulnerability has been resolved: coresight: trbe: remove cpuhp instance node before remove cpuhp state cpuhp_state_add_instance() and cpuhp_state_remove_instance() should be used in pairs. Or there will lead to the warn on cpuhp_remove_multi_state() since the cpuhp_step list is not empty. The following is the error log

CVE-2023-53248 [MEDIUM] CWE-476 CVE-2023-53248: In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: install stub fence In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: install stub fence into potential unused fence pointers When using cpu to update page tables, vm update fences are unused. Install stub fence into these fence pointers instead of NULL to avoid NULL dereference when calling dma_fence_wait() on them.

CVE-2022-50331 [MEDIUM] CWE-401 CVE-2022-50331: In the Linux kernel, the following vulnerability has been resolved: wwan_hwsim: fix possible memory In the Linux kernel, the following vulnerability has been resolved: wwan_hwsim: fix possible memory leak in wwan_hwsim_dev_new() Inject fault while probing module, if device_register() fails, but the refcount of kobject is not decreased to 0, the name allocated in dev_set_name() is leaked. Fix this by calling put_device(), so that name can be free

CVE-2023-53204 [MEDIUM] CWE-362 CVE-2023-53204: In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix data-races around In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix data-races around user->unix_inflight. user->unix_inflight is changed under spin_lock(unix_gc_lock), but too_many_unix_fds() reads it locklessly. Let's annotate the write/read accesses to user->unix_inflight. BUG: KCSAN: data-race in unix_attach_fds / unix_inflight

CVE-2023-53174 [MEDIUM] CWE-401 CVE-2023-53174: In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix possible memory In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix possible memory leak if device_add() fails If device_add() returns error, the name allocated by dev_set_name() needs be freed. As the comment of device_add() says, put_device() should be used to decrease the reference count in the error path. So fix this by calling

CVE-2023-53210 [MEDIUM] CWE-476 CVE-2023-53210: In the Linux kernel, the following vulnerability has been resolved: md/raid5-cache: fix null-ptr-de In the Linux kernel, the following vulnerability has been resolved: md/raid5-cache: fix null-ptr-deref for r5l_flush_stripe_to_raid() r5l_flush_stripe_to_raid() will check if the list 'flushing_ios' is empty, and then submit 'flush_bio', however, r5l_log_flush_endio() is clearing the list first and then clear the bio, which will cause null-ptr-der

CVE-2023-53206 [MEDIUM] CWE-476 CVE-2023-53206: In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus_core) Fix NULL po In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus_core) Fix NULL pointer dereference Pass i2c_client to _pmbus_is_enabled to drop the assumption that a regulator device is passed in. This will fix the issue of a NULL pointer dereference when called from _pmbus_get_flags.

CVE-2023-53260 [MEDIUM] CWE-476 CVE-2023-53260: In the Linux kernel, the following vulnerability has been resolved: ovl: fix null pointer dereferen In the Linux kernel, the following vulnerability has been resolved: ovl: fix null pointer dereference in ovl_permission() Following process: P1 P2 path_lookupat link_path_walk inode_permission ovl_permission ovl_i_path_real(inode, &realpath) path->dentry = ovl_i_dentry_upper(inode) drop_cache __dentry_kill(ovl_dentry) iput(ovl_inode) ovl_destroy_i

CVE-2022-50316 [MEDIUM] CWE-401 CVE-2022-50316: In the Linux kernel, the following vulnerability has been resolved: orangefs: Fix kmemleak in orang In the Linux kernel, the following vulnerability has been resolved: orangefs: Fix kmemleak in orangefs_sysfs_init() When insert and remove the orangefs module, there are kobjects memory leaked as below: unreferenced object 0xffff88810f95af00 (size 64): comm "insmod", pid 783, jiffies 4294813439 (age 65.512s) hex dump (first 32 bytes): a0 83 af 01

CVE-2023-53147 [MEDIUM] CWE-476 CVE-2023-53147: In the Linux kernel, the following vulnerability has been resolved: xfrm: add NULL check in xfrm_up In the Linux kernel, the following vulnerability has been resolved: xfrm: add NULL check in xfrm_update_ae_params Normally, x->replay_esn and x->preplay_esn should be allocated at xfrm_alloc_replay_state_esn(...) in xfrm_state_construct(...), hence the xfrm_update_ae_params(...) is okay to update them. However, the current implementation of xfrm_n

CVE-2022-50263 [MEDIUM] CWE-401 CVE-2022-50263: In the Linux kernel, the following vulnerability has been resolved: vdpasim: fix memory leak when f In the Linux kernel, the following vulnerability has been resolved: vdpasim: fix memory leak when freeing IOTLBs After commit bda324fd037a ("vdpasim: control virtqueue support"), vdpasim->iommu became an array of IOTLB, so we should clean the mappings of each free one by one instead of just deleting the ranges in the first IOTLB which may leak map

CVE-2022-50247 [MEDIUM] CWE-401 CVE-2022-50247: In the Linux kernel, the following vulnerability has been resolved: usb: xhci-mtk: fix leakage of s In the Linux kernel, the following vulnerability has been resolved: usb: xhci-mtk: fix leakage of shared hcd when fail to set wakeup irq Can not set the @shared_hcd to NULL before decrease the usage count by usb_put_hcd(), this will cause the shared hcd not released.

CVE-2023-53261 [MEDIUM] CWE-401 CVE-2023-53261: In the Linux kernel, the following vulnerability has been resolved: coresight: Fix memory leak in a In the Linux kernel, the following vulnerability has been resolved: coresight: Fix memory leak in acpi_buffer->pointer There are memory leaks reported by kmemleak: ... unreferenced object 0xffff00213c141000 (size 1024): comm "systemd-udevd", pid 2123, jiffies 4294909467 (age 6062.160s) hex dump (first 32 bytes): 04 00 00 00 02 00 00 00 18 10 14 3c

CVE-2023-53173 [MEDIUM] CWE-401 CVE-2023-53173: In the Linux kernel, the following vulnerability has been resolved: tty: pcn_uart: fix memory leak In the Linux kernel, the following vulnerability has been resolved: tty: pcn_uart: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.

CVE-2022-50253 [MEDIUM] CVE-2022-50253: In the Linux kernel, the following vulnerability has been resolved: bpf: make sure skb->len != 0 wh In the Linux kernel, the following vulnerability has been resolved: bpf: make sure skb->len != 0 when redirecting to a tunneling device syzkaller managed to trigger another case where skb->len == 0 when we enter __dev_queue_xmit: WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 skb_assert_len include/linux/skbuff.h:2576 [inline] WARNING: CPU: 0 P

CVE-2022-50330 [MEDIUM] CWE-190 CVE-2022-50330: In the Linux kernel, the following vulnerability has been resolved: crypto: cavium - prevent intege In the Linux kernel, the following vulnerability has been resolved: crypto: cavium - prevent integer overflow loading firmware The "code_length" value comes from the firmware file. If your firmware is untrusted realistically there is probably very little you can do to protect yourself. Still we try to limit the damage as much as possible. Also Sma

CVE-2023-53193 [MEDIUM] CVE-2023-53193: In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix amdgpu_irq_put In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix amdgpu_irq_put call trace in gmc_v10_0_hw_fini The gmc.ecc_irq is enabled by firmware per IFWI setting, and the host driver is not privileged to enable/disable the interrupt. So, it is meaningless to use the amdgpu_irq_put function in gmc_v10_0_hw_fini, which also leads to

CVE-2023-53211 [MEDIUM] CWE-401 CVE-2023-53211: In the Linux kernel, the following vulnerability has been resolved: driver core: location: Free str In the Linux kernel, the following vulnerability has been resolved: driver core: location: Free struct acpi_pld_info *pld before return false struct acpi_pld_info *pld should be freed before the return of allocation failure, to prevent memory leak, add the ACPI_FREE() to fix it.

CVE-2022-50280 [MEDIUM] CWE-476 CVE-2022-50280: In the Linux kernel, the following vulnerability has been resolved: pnode: terminate at peers of so In the Linux kernel, the following vulnerability has been resolved: pnode: terminate at peers of source The propagate_mnt() function handles mount propagation when creating mounts and propagates the source mount tree @source_mnt to all applicable nodes of the destination propagation mount tree headed by @dest_mnt. Unfortunately it contains a bug

CVE-2022-50297 [MEDIUM] CVE-2022-50297: In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: verify the expecte In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: verify the expected usb_endpoints are present The bug arises when a USB device claims to be an ATH9K but doesn't have the expected endpoints. (In this case there was an interrupt endpoint where the driver expected a bulk endpoint.) The kernel needs to be able to handle such d