p PatchFirst

PatchFirst · Latest vulnerabilities

linux-aws-5.4 vulnerabilities · Page 22

Vulnerabilities published for linux-aws-5.4 in the last 30 days: 0. Listed in the KEV catalogue: 0.

Filter vulnerabilities
Clear filters

Vulnerabilities: 1757

  1. CVE-2022-49835

    Medium · CVSS 5.5EPSS 0.2%Fix available

    ALSA: hda: fix potential memleak in 'add_widget_node'

    In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: fix potential memleak in 'add_widget_node' As 'kobject_add' may allocated memory for 'kobject->name' when return error. And in this function, if call 'kobject_add' failed didn't free kobject. So call 'kobject_put' to recycling resources.

    • Update to 5.4.0-1097.105~18.04.1
  2. CVE-2022-49834

    High · CVSS 7.8EPSS 0.22%Fix available

    nilfs2: fix use-after-free bug of ns_writer on remount

    In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix use-after-free bug of ns_writer on remount If a nilfs2 filesystem is downgraded to read-only due to metadata corruption on disk and is remounted read/write, or if emergency read-only remount is performed, detaching a log writer and synchronizing the filesystem can be done at the same time. In these cases, use-after-free of the log writer (hereinafter nilfs->ns_writer) can happen as shown in the scenario below: Task1 Task2 -------------------------------- ------------------------------ nilfs_construct_segment nilfs_segctor

    • Update to 5.4.0-1097.105~18.04.1
    Published Updated
  3. CVE-2022-49832

    Medium · CVSS 5.5EPSS 0.22%Fix available

    pinctrl: devicetree: fix null pointer dereferencing in pinctrl_dt_to_map

    In the Linux kernel, the following vulnerability has been resolved: pinctrl: devicetree: fix null pointer dereferencing in pinctrl_dt_to_map Here is the BUG report by KASAN about null pointer dereference: BUG: KASAN: null-ptr-deref in strcmp+0x2e/0x50 Read of size 1 at addr 0000000000000000 by task python3/2640 Call Trace: strcmp __of_find_property of_find_property pinctrl_dt_to_map kasprintf() would return NULL pointer when kmalloc() fail to allocate. So directly return ENOMEM, if kasprintf() return NULL pointer.

    • Update to 5.4.0-1097.105~18.04.1
  4. CVE-2022-49826

    High · CVSS 7.8EPSS 0.23%Fix available

    ata: libata-transport: fix double ata_host_put() in ata_tport_add()

    In the Linux kernel, the following vulnerability has been resolved: ata: libata-transport: fix double ata_host_put() in ata_tport_add() In the error path in ata_tport_add(), when calling put_device(), ata_tport_release() is called, it will put the refcount of 'ap->host'. And then ata_host_put() is called again, the refcount is decreased to 0, ata_host_release() is called, all ports are freed and set to null. When unbinding the device after failure, ata_host_stop() is called to release the resources, it leads a null-ptr-deref(), because all the ports all freed and null. Unable to handle kernel NULL pointer dereference at virtual address 0

    • Update to 5.4.0-1097.105~18.04.1
    Published Updated
  5. CVE-2022-49821

    Medium · CVSS 5.5EPSS 0.2%Fix available

    mISDN: fix possible memory leak in mISDN_dsp_element_register()

    In the Linux kernel, the following vulnerability has been resolved: mISDN: fix possible memory leak in mISDN_dsp_element_register() Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, use put_device() to give up the reference, so that the name can be freed in kobject_cleanup() when the refcount is 0. The 'entry' is going to be freed in mISDN_dsp_dev_release(), so the kfree() is removed. list_del() is called in mISDN_dsp_dev_release(), so it need be initialized.

    • Update to 5.4.0-1097.105~18.04.1
  6. CVE-2022-49814

    High · CVSS 7.8EPSS 0.17%Fix available

    kcm: close race conditions on sk_receive_queue

    In the Linux kernel, the following vulnerability has been resolved: kcm: close race conditions on sk_receive_queue sk->sk_receive_queue is protected by skb queue lock, but for KCM sockets its RX path takes mux->rx_lock to protect more than just skb queue. However, kcm_recvmsg() still only grabs the skb queue lock, so race conditions still exist. We can teach kcm_recvmsg() to grab mux->rx_lock too but this would introduce a potential performance regression as struct kcm_mux can be shared by multiple KCM sockets. So we have to enforce skb queue lock in requeue_rx_msgs() and handle skb peek case carefully in kcm_wait_data(). Fortunately, skb

    • Update to 5.4.0-1097.105~18.04.1
    Published Updated
  7. CVE-2022-49809

    High · CVSS 7.1EPSS 0.2%Fix available

    net/x25: Fix skb leak in x25_lapb_receive_frame()

    In the Linux kernel, the following vulnerability has been resolved: net/x25: Fix skb leak in x25_lapb_receive_frame() x25_lapb_receive_frame() using skb_copy() to get a private copy of skb, the new skb should be freed in the undersized/fragmented skb error handling path. Otherwise there is a memory leak.

    • Update to 5.4.0-1097.105~18.04.1
  8. CVE-2022-49802

    Medium · CVSS 5.5EPSS 0.22%Fix available

    ftrace: Fix null pointer dereference in ftrace_add_mod()

    In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix null pointer dereference in ftrace_add_mod() The @ftrace_mod is allocated by kzalloc(), so both the members {prev,next} of @ftrace_mode->list are NULL, it's not a valid state to call list_del(). If kstrdup() for @ftrace_mod->{func|module} fails, it goes to @out_free tag and calls free_ftrace_mod() to destroy @ftrace_mod, then list_del() will write prev->next and next->prev, where null pointer dereference happens. BUG: kernel NULL pointer dereference, address: 0000000000000008 Oops: 0002 [#1] PREEMPT SMP NOPTI Call Trace: <TASK> ftrace_mod_callback+0x20d/0x220

    • Update to 5.4.0-1097.105~18.04.1
  9. CVE-2022-49794

    Medium · CVSS 5.5EPSS 0.2%Fix available

    iio: adc: at91_adc: fix possible memory leak in at91_adc_allocate_trigger()

    In the Linux kernel, the following vulnerability has been resolved: iio: adc: at91_adc: fix possible memory leak in at91_adc_allocate_trigger() If iio_trigger_register() returns error, it should call iio_trigger_free() to give up the reference that hold in iio_trigger_alloc(), so that it can call iio_trig_release() to free memory when the refcount hit to 0.

    • Update to 5.4.0-1097.105~18.04.1
  10. CVE-2022-49793

    Medium · CVSS 5.5EPSS 0.23%Fix available

    iio: trigger: sysfs: fix possible memory leak in iio_sysfs_trig_init()

    In the Linux kernel, the following vulnerability has been resolved: iio: trigger: sysfs: fix possible memory leak in iio_sysfs_trig_init() dev_set_name() allocates memory for name, it need be freed when device_add() fails, call put_device() to give up the reference that hold in device_initialize(), so that it can be freed in kobject_cleanup() when the refcount hit to 0. Fault injection test can trigger this: unreferenced object 0xffff8e8340a7b4c0 (size 32): comm "modprobe", pid 243, jiffies 4294678145 (age 48.845s) hex dump (first 32 bytes): 69 69 6f 5f 73 79 73 66 73 5f 74 72 69 67 67 65 iio_sysfs_trigge 72 00 a7 40 83 8e ff

    • Update to 5.4.0-1097.105~18.04.1
  11. CVE-2022-49790

    Medium · CVSS 5.5EPSS 0.2%Fix available

    Input: iforce - invert valid length check when fetching device IDs

    In the Linux kernel, the following vulnerability has been resolved: Input: iforce - invert valid length check when fetching device IDs syzbot is reporting uninitialized value at iforce_init_device() [1], for commit 6ac0aec6b0a6 ("Input: iforce - allow callers supply data buffer when fetching device IDs") is checking that valid length is shorter than bytes to read. Since iforce_get_id_packet() stores valid length when returning 0, the caller needs to check that valid length is longer than or equals to bytes to read.

    • Update to 5.4.0-1097.105~18.04.1
  12. CVE-2022-49789

    High · CVSS 7EPSS 0.2%Fix available

    scsi: zfcp: Fix double free of FSF request when qdio send fails

    In the Linux kernel, the following vulnerability has been resolved: scsi: zfcp: Fix double free of FSF request when qdio send fails We used to use the wrong type of integer in 'zfcp_fsf_req_send()' to cache the FSF request ID when sending a new FSF request. This is used in case the sending fails and we need to remove the request from our internal hash table again (so we don't keep an invalid reference and use it when we free the request again). In 'zfcp_fsf_req_send()' we used to cache the ID as 'int' (signed and 32 bit wide), but the rest of the zfcp code (and the firmware specification) handles the ID as 'unsigned long'/'u64' (unsigned a

    • Update to 5.4.0-1097.105~18.04.1
    Published Updated
  13. CVE-2022-49788

    Medium · CVSS 5.5EPSS 0.23%Fix available

    misc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram()

    In the Linux kernel, the following vulnerability has been resolved: misc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram() `struct vmci_event_qp` allocated by qp_notify_peer() contains padding, which may carry uninitialized data to the userspace, as observed by KMSAN: BUG: KMSAN: kernel-infoleak in instrument_copy_to_user ./include/linux/instrumented.h:121 instrument_copy_to_user ./include/linux/instrumented.h:121 _copy_to_user+0x5f/0xb0 lib/usercopy.c:33 copy_to_user ./include/linux/uaccess.h:169 vmci_host_do_receive_datagram drivers/misc/vmw_vmci/vmci_host.c:431 vmci_host_unlocked_ioctl+0x33d/0x43d0 drivers/mi

    • Update to 5.4.0-1097.105~18.04.1
  14. CVE-2022-49787

    Medium · CVSS 5.5EPSS 0.22%Fix available

    mmc: sdhci-pci: Fix possible memory leak caused by missing pci_dev_put()

    In the Linux kernel, the following vulnerability has been resolved: mmc: sdhci-pci: Fix possible memory leak caused by missing pci_dev_put() pci_get_device() will increase the reference count for the returned pci_dev. We need to use pci_dev_put() to decrease the reference count before amd_probe() returns. There is no problem for the 'smbus_dev == NULL' branch because pci_dev_put() can also handle the NULL input parameter case.

    • Update to 5.4.0-1097.105~18.04.1
  15. CVE-2022-49780

    Medium · CVSS 5.5EPSS 0.22%Fix available

    scsi: target: tcm_loop: Fix possible name leak in tcm_loop_setup_hba_bus()

    In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix possible name leak in tcm_loop_setup_hba_bus() If device_register() fails in tcm_loop_setup_hba_bus(), the name allocated by dev_set_name() need be freed. As comment of device_register() says, it should use put_device() to give up the reference in the error path. So fix this by calling put_device(), then the name can be freed in kobject_cleanup(). The 'tl_hba' will be freed in tcm_loop_release_adapter(), so it don't need goto error label in this case.

    • Update to 5.4.0-1097.105~18.04.1
  16. CVE-2022-49779

    High · CVSS 7.8EPSS 0.22%Fix available

    kprobes: Skip clearing aggrprobe's post_handler in kprobe-on-ftrace case

    In the Linux kernel, the following vulnerability has been resolved: kprobes: Skip clearing aggrprobe's post_handler in kprobe-on-ftrace case In __unregister_kprobe_top(), if the currently unregistered probe has post_handler but other child probes of the aggrprobe do not have post_handler, the post_handler of the aggrprobe is cleared. If this is a ftrace-based probe, there is a problem. In later calls to disarm_kprobe(), we will use kprobe_ftrace_ops because post_handler is NULL. But we're armed with kprobe_ipmodify_ops. This triggers a WARN in __disarm_kprobe_ftrace() and may even cause use-after-free: Failed to disarm kprobe-ftrace at k

    • Update to 5.4.0-1097.105~18.04.1
  17. CVE-2022-49777

    Medium · CVSS 5.5EPSS 0.22%Fix available

    Input: i8042 - fix leaking of platform device on module removal

    In the Linux kernel, the following vulnerability has been resolved: Input: i8042 - fix leaking of platform device on module removal Avoid resetting the module-wide i8042_platform_device pointer in i8042_probe() or i8042_remove(), so that the device can be properly destroyed by i8042_exit() on module unload.

    • Update to 5.4.0-1097.105~18.04.1
  18. CVE-2022-49776

    Medium · CVSS 6.8EPSS 0.22%Fix available

    macvlan: enforce a consistent minimal mtu

    In the Linux kernel, the following vulnerability has been resolved: macvlan: enforce a consistent minimal mtu macvlan should enforce a minimal mtu of 68, even at link creation. This patch avoids the current behavior (which could lead to crashes in ipv6 stack if the link is brought up) $ ip link add macvlan1 link eno1 mtu 8 type macvlan # This should fail ! $ ip link sh dev macvlan1 5: macvlan1@eno1: <BROADCAST,MULTICAST> mtu 8 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 02:47:6c:24:74:82 brd ff:ff:ff:ff:ff:ff $ ip link set macvlan1 mtu 67 Error: mtu less than device minimum. $ ip link set macvlan1 mtu 68

    • Update to 5.4.0-1097.105~18.04.1

Check your server

Check your installed stack and versions against the current vulnerability feeds.

Check your server →