p PatchFirst

PatchFirst · Latest vulnerabilities

linux-azure vulnerabilities · Page 58

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

Filter vulnerabilities
Clear filters

Vulnerabilities: 3442

  1. CVE-2022-49337

    High · CVSS 7.8EPSS 0.21%Fix available

    ocfs2: dlmfs: fix error handling of user_dlm_destroy_lock

    In the Linux kernel, the following vulnerability has been resolved: ocfs2: dlmfs: fix error handling of user_dlm_destroy_lock When user_dlm_destroy_lock failed, it didn't clean up the flags it set before exit. For USER_LOCK_IN_TEARDOWN, if this function fails because of lock is still in used, next time when unlink invokes this function, it will return succeed, and then unlink will remove inode and dentry if lock is not in used(file closed), but the dlm lock is still linked in dlm lock resource, then when bast come in, it will trigger a panic due to user-after-free. See the following panic call trace. To fix this, USER_LOCK_IN_TEARDOWN sh

    • Update to 5.4.0-1091.96
    Published Updated
  2. CVE-2022-49336

    High · CVSS 7.8EPSS 0.28%Fix available

    drm/etnaviv: check for reaped mapping in etnaviv_iommu_unmap_gem

    In the Linux kernel, the following vulnerability has been resolved: drm/etnaviv: check for reaped mapping in etnaviv_iommu_unmap_gem When the mapping is already reaped the unmap must be a no-op, as we would otherwise try to remove the mapping twice, corrupting the involved data structures.

    • Update to 5.4.0-1091.96
    Published Updated
  3. CVE-2022-49335

    Medium · CVSS 5.5EPSS 0.28%Fix available

    drm/amdgpu/cs: make commands with 0 chunks illegal behaviour.

    In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/cs: make commands with 0 chunks illegal behaviour. Submitting a cs with 0 chunks, causes an oops later, found trying to execute the wrong userspace driver. MESA_LOADER_DRIVER_OVERRIDE=v3d glxinfo [172536.665184] BUG: kernel NULL pointer dereference, address: 00000000000001d8 [172536.665188] #PF: supervisor read access in kernel mode [172536.665189] #PF: error_code(0x0000) - not-present page [172536.665191] PGD 6712a0067 P4D 6712a0067 PUD 5af9ff067 PMD 0 [172536.665195] Oops: 0000 [#1] SMP NOPTI [172536.665197] CPU: 7 PID: 2769838 Comm: glxinfo Tainted: P

    • Update to 5.4.0-1091.96
    Published Updated
  4. CVE-2022-49330

    High · CVSS 7.5EPSS 0.83%Fix available

    tcp: fix tcp_mtup_probe_success vs wrong snd_cwnd

    In the Linux kernel, the following vulnerability has been resolved: tcp: fix tcp_mtup_probe_success vs wrong snd_cwnd syzbot got a new report [1] finally pointing to a very old bug, added in initial support for MTU probing. tcp_mtu_probe() has checks about starting an MTU probe if tcp_snd_cwnd(tp) >= 11. But nothing prevents tcp_snd_cwnd(tp) to be reduced later and before the MTU probe succeeds. This bug would lead to potential zero-divides. Debugging added in commit 40570375356c ("tcp: add accessors to read/set tp->snd_cwnd") has paid off :) While we are at it, address potential overflows in this code. [1] WARNING: CPU: 1 PID: 14132

    • Update to 5.4.0-1091.96
    Published Updated
  5. CVE-2022-49326

    Medium · CVSS 5.5EPSS 0.3%Fix available

    rtl818x: Prevent using not initialized queues

    In the Linux kernel, the following vulnerability has been resolved: rtl818x: Prevent using not initialized queues Using not existing queues can panic the kernel with rtl8180/rtl8185 cards. Ignore the skb priority for those cards, they only have one tx queue. Pierre Asselin ([email protected]) reported the kernel crash in the Gentoo forum: https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html He also confirmed that this patch fixes the issue. In summary this happened: After updating wpa_supplicant from 2.9 to 2.10 the kernel crashed with a "divide error: 0000" when connecting to an AP. Control port tx now tries t

    • Update to 5.4.0-1091.96
    Published Updated
  6. CVE-2022-49322

    Medium · CVSS 5.5EPSS 0.21%Fix available

    tracing: Fix sleeping function called from invalid context on RT kernel

    In the Linux kernel, the following vulnerability has been resolved: tracing: Fix sleeping function called from invalid context on RT kernel When setting bootparams="trace_event=initcall:initcall_start tp_printk=1" in the cmdline, the output_printk() was called, and the spin_lock_irqsave() was called in the atomic and irq disable interrupt context suitation. On the PREEMPT_RT kernel, these locks are replaced with sleepable rt-spinlock, so the stack calltrace will be triggered. Fix it by raw_spin_lock_irqsave when PREEMPT_RT and "trace_event=initcall:initcall_start tp_printk=1" enabled. BUG: sleeping function called from invalid context at

    • Update to 5.4.0-1091.96
    Published Updated
  7. CVE-2022-49321

    High · CVSS 7.5EPSS 0.77%Fix available

    xprtrdma: treat all calls not a bcall when bc_serv is NULL

    In the Linux kernel, the following vulnerability has been resolved: xprtrdma: treat all calls not a bcall when bc_serv is NULL When a rdma server returns a fault format reply, nfs v3 client may treats it as a bcall when bc service is not exist. The debug message at rpcrdma_bc_receive_call are, [56579.837169] RPC: rpcrdma_bc_receive_call: callback XID 00000001, length=20 [56579.837174] RPC: rpcrdma_bc_receive_call: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 After that, rpcrdma_bc_receive_call will meets NULL pointer as, [ 226.057890] BUG: unable to handle kernel NULL pointer dereference at 00000000000000c8 .

    • Update to 5.4.0-1091.96
    Published Updated
  8. CVE-2022-49320

    Medium · CVSS 5.5EPSS 0.27%Fix available

    dmaengine: zynqmp_dma: In struct zynqmp_dma_chan fix desc_size data type

    In the Linux kernel, the following vulnerability has been resolved: dmaengine: zynqmp_dma: In struct zynqmp_dma_chan fix desc_size data type In zynqmp_dma_alloc/free_chan_resources functions there is a potential overflow in the below expressions. dma_alloc_coherent(chan->dev, (2 * chan->desc_size * ZYNQMP_DMA_NUM_DESCS), &chan->desc_pool_p, GFP_KERNEL); dma_free_coherent(chan->dev,(2 * ZYNQMP_DMA_DESC_SIZE(chan) * ZYNQMP_DMA_NUM_DESCS), chan->desc_pool_v, chan->desc_pool_p); The arguments desc_size and ZYNQMP_DMA_NUM_DESCS were 32 bit. Though this overflow condition is not observed but it is a p

    • Update to 5.4.0-1091.96
    Published Updated
  9. CVE-2022-49318

    Medium · CVSS 5.5EPSS 0.26%Fix available

    f2fs: remove WARN_ON in f2fs_is_valid_blkaddr

    In the Linux kernel, the following vulnerability has been resolved: f2fs: remove WARN_ON in f2fs_is_valid_blkaddr Syzbot triggers two WARNs in f2fs_is_valid_blkaddr and __is_bitmap_valid. For example, in f2fs_is_valid_blkaddr, if type is DATA_GENERIC_ENHANCE or DATA_GENERIC_ENHANCE_READ, it invokes WARN_ON if blkaddr is not in the right range. The call trace is as follows: f2fs_get_node_info+0x45f/0x1070 read_node_page+0x577/0x1190 __get_node_page.part.0+0x9e/0x10e0 __get_node_page f2fs_get_node_page+0x109/0x180 do_read_inode f2fs_iget+0x2a5/0x58b0 f2fs_fill_super+0x3b39/0x7ca0 Fix these two WARNs by replacing WARN_ON with dump_st

    • Update to 5.4.0-1091.96
    Published Updated
  10. CVE-2022-49316

    Medium · CVSS 5.5EPSS 0.21%Fix available

    NFSv4: Don't hold the layoutget locks across multiple RPC calls

    In the Linux kernel, the following vulnerability has been resolved: NFSv4: Don't hold the layoutget locks across multiple RPC calls When doing layoutget as part of the open() compound, we have to be careful to release the layout locks before we can call any further RPC calls, such as setattr(). The reason is that those calls could trigger a recall, which could deadlock.

    • Update to 5.4.0-1091.96
    Published Updated
  11. CVE-2022-49315

    Medium · CVSS 5.5EPSS 0.21%Fix available

    drivers: staging: rtl8192e: Fix deadlock in rtllib_beacons_stop()

    In the Linux kernel, the following vulnerability has been resolved: drivers: staging: rtl8192e: Fix deadlock in rtllib_beacons_stop() There is a deadlock in rtllib_beacons_stop(), which is shown below: (Thread 1) | (Thread 2) | rtllib_send_beacon() rtllib_beacons_stop() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | rtllib_send_beacon_cb() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ... We hold ieee->beacon_lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler

    • Update to 5.4.0-1091.96
    Published Updated
  12. CVE-2022-49314

    Medium · CVSS 5.5EPSS 0.28%Fix available

    tty: Fix a possible resource leak in icom_probe

    In the Linux kernel, the following vulnerability has been resolved: tty: Fix a possible resource leak in icom_probe When pci_read_config_dword failed, call pci_release_regions() and pci_disable_device() to recycle the resource previously allocated.

    • Update to 5.4.0-1091.96
    Published Updated
  13. CVE-2022-49313

    Medium · CVSS 5.5EPSS 0.21%Fix available

    drivers: usb: host: Fix deadlock in oxu_bus_suspend()

    In the Linux kernel, the following vulnerability has been resolved: drivers: usb: host: Fix deadlock in oxu_bus_suspend() There is a deadlock in oxu_bus_suspend(), which is shown below: (Thread 1) | (Thread 2) | timer_action() oxu_bus_suspend() | mod_timer() spin_lock_irq() //(1) | (wait a time) ... | oxu_watchdog() del_timer_sync() | spin_lock_irq() //(2) (wait timer to stop) | ... We hold oxu->lock in position (1) of thread 1, and use del_timer_sync() to wait timer to stop, but timer handler also need oxu->lock in position (2) of thr

    • Update to 5.4.0-1091.96
    Published Updated
  14. CVE-2022-49308

    Medium · CVSS 5.5EPSS 0.28%Fix available

    extcon: Modify extcon device to be created after driver data is set

    In the Linux kernel, the following vulnerability has been resolved: extcon: Modify extcon device to be created after driver data is set Currently, someone can invoke the sysfs such as state_show() intermittently before dev_set_drvdata() is done. And it can be a cause of kernel Oops because of edev is Null at that time. So modified the driver registration to after setting drviver data. - Oops's backtrace. Backtrace: [<c067865c>] (state_show) from [<c05222e8>] (dev_attr_show) [<c05222c0>] (dev_attr_show) from [<c02c66e0>] (sysfs_kf_seq_show) [<c02c6648>] (sysfs_kf_seq_show) from [<c02c496c>] (kernfs_seq_show) [<c02c4938>] (kernfs_seq_show)

    • Update to 5.4.0-1091.96
    Published Updated
  15. CVE-2022-49307

    Medium · CVSS 5.5EPSS 0.29%Fix available

    tty: synclink_gt: Fix null-pointer-dereference in slgt_clean()

    In the Linux kernel, the following vulnerability has been resolved: tty: synclink_gt: Fix null-pointer-dereference in slgt_clean() When the driver fails at alloc_hdlcdev(), and then we remove the driver module, we will get the following splat: [ 25.065966] general protection fault, probably for non-canonical address 0xdffffc0000000182: 0000 [#1] PREEMPT SMP KASAN PTI [ 25.066914] KASAN: null-ptr-deref in range [0x0000000000000c10-0x0000000000000c17] [ 25.069262] RIP: 0010:detach_hdlc_protocol+0x2a/0x3e0 [ 25.077709] Call Trace: [ 25.077924] <TASK> [ 25.078108] unregister_hdlc_device+0x16/0x30 [ 25.078481] slgt_cleanup+0x15

    • Update to 5.4.0-1091.96
    Published Updated
  16. CVE-2022-49305

    Medium · CVSS 5.5EPSS 0.2%Fix available

    drivers: staging: rtl8192u: Fix deadlock in ieee80211_beacons_stop()

    In the Linux kernel, the following vulnerability has been resolved: drivers: staging: rtl8192u: Fix deadlock in ieee80211_beacons_stop() There is a deadlock in ieee80211_beacons_stop(), which is shown below: (Thread 1) | (Thread 2) | ieee80211_send_beacon() ieee80211_beacons_stop() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | ieee80211_send_beacon_cb() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ... We hold ieee->beacon_lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but ti

    • Update to 5.4.0-1091.96
    Published Updated
  17. CVE-2022-49304

    Medium · CVSS 5.5EPSS 0.2%Fix available

    drivers: tty: serial: Fix deadlock in sa1100_set_termios()

    In the Linux kernel, the following vulnerability has been resolved: drivers: tty: serial: Fix deadlock in sa1100_set_termios() There is a deadlock in sa1100_set_termios(), which is shown below: (Thread 1) | (Thread 2) | sa1100_enable_ms() sa1100_set_termios() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | sa1100_timeout() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ... We hold sport->port.lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need sport->p

    • Update to 5.4.0-1091.96
    Published Updated
  18. CVE-2022-49302

    Medium · CVSS 5.5EPSS 0.27%Fix available

    USB: host: isp116x: check return value after calling platform_get_resource()

    In the Linux kernel, the following vulnerability has been resolved: USB: host: isp116x: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value.

    • Update to 5.4.0-1091.96
    Published Updated

Check your server

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

Check your server →