p PatchFirst

PatchFirst · Aktuelle Sicherheitslücken

Sicherheitslücken in linux-azure-4.15 · Seite 187

In den letzten 30 Tagen veröffentlichte Sicherheitslücken für linux-azure-4.15: 408. Davon im KEV-Katalog: 0.

Sicherheitslücken filtern
Filter zurücksetzen

Sicherheitslücken: 5711

  1. CVE-2022-50090

    Hoch · CVSS 7.8EPSS 0,2%Keine Korrektur veröffentlicht

    btrfs: replace BTRFS_MAX_EXTENT_SIZE with fs_info->max_extent_size

    In the Linux kernel, the following vulnerability has been resolved: btrfs: replace BTRFS_MAX_EXTENT_SIZE with fs_info->max_extent_size On zoned filesystem, data write out is limited by max_zone_append_size, and a large ordered extent is split according the size of a bio. OTOH, the number of extents to be written is calculated using BTRFS_MAX_EXTENT_SIZE, and that estimated number is used to reserve the metadata bytes to update and/or create the metadata items. The metadata reservation is done at e.g, btrfs_buffered_write() and then released according to the estimation changes. Thus, if the number of extent increases massively, the reserved

    Veröffentlicht Aktualisiert
  2. CVE-2022-50087

    Hoch · CVSS 7.8EPSS 0,2%Keine Korrektur veröffentlicht

    firmware: arm_scpi: Ensure scpi_info is not assigned if the probe fails

    In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scpi: Ensure scpi_info is not assigned if the probe fails When scpi probe fails, at any point, we need to ensure that the scpi_info is not set and will remain NULL until the probe succeeds. If it is not taken care, then it could result use-after-free as the value is exported via get_scpi_ops() and could refer to a memory allocated via devm_kzalloc() but freed when the probe fails.

    Veröffentlicht Aktualisiert
  3. CVE-2022-50073

    Hoch · CVSS 8.2EPSS 0,21%Keine Korrektur veröffentlicht

    net: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is null

    In the Linux kernel, the following vulnerability has been resolved: net: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is null Fixes a NULL pointer derefence bug triggered from tap driver. When tap_get_user calls virtio_net_hdr_to_skb the skb->dev is null (in tap.c skb->dev is set after the call to virtio_net_hdr_to_skb) virtio_net_hdr_to_skb calls dev_parse_header_protocol which needs skb->dev field to be valid. The line that trigers the bug is in dev_parse_header_protocol (dev is at offset 0x10 from skb and is stored in RAX register) if (!dev->header_ops || !dev->header_ops->parse_protocol) 22e1: mov 0x1

    Veröffentlicht Aktualisiert
  4. CVE-2022-50066

    Hoch · CVSS 7.8EPSS 0,2%Keine Korrektur veröffentlicht

    net: atlantic: fix aq_vec index out of range error

    In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix aq_vec index out of range error The final update statement of the for loop exceeds the array range, the dereference of self->aq_vec[i] is not checked and then leads to the index out of range error. Also fixed this kind of coding style in other for loop. [ 97.937604] UBSAN: array-index-out-of-bounds in drivers/net/ethernet/aquantia/atlantic/aq_nic.c:1404:48 [ 97.937607] index 8 is out of range for type 'aq_vec_s *[8]' [ 97.937608] CPU: 38 PID: 3767 Comm: kworker/u256:18 Not tainted 5.19.0+ #2 [ 97.937610] Hardware name: Dell Inc. Precision 7865 To

    Veröffentlicht Aktualisiert
  5. CVE-2022-50065

    Hoch · CVSS 8.2EPSS 0,19%Keine Korrektur veröffentlicht

    virtio_net: fix memory leak inside XPD_TX with mergeable

    In the Linux kernel, the following vulnerability has been resolved: virtio_net: fix memory leak inside XPD_TX with mergeable When we call xdp_convert_buff_to_frame() to get xdpf, if it returns NULL, we should check if xdp_page was allocated by xdp_linearize_page(). If it is newly allocated, it should be freed here alone. Just like any other "goto err_xdp".

    Veröffentlicht Aktualisiert
  6. CVE-2022-50062

    Hoch · CVSS 7.5EPSS 0,44%Keine Korrektur veröffentlicht

    net: bgmac: Fix a BUG triggered by wrong bytes_compl

    In the Linux kernel, the following vulnerability has been resolved: net: bgmac: Fix a BUG triggered by wrong bytes_compl On one of our machines we got: kernel BUG at lib/dynamic_queue_limits.c:27! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM CPU: 0 PID: 1166 Comm: irq/41-bgmac Tainted: G W O 4.14.275-rt132 #1 Hardware name: BRCM XGS iProc task: ee3415c0 task.stack: ee32a000 PC is at dql_completed+0x168/0x178 LR is at bgmac_poll+0x18c/0x6d8 pc : [<c03b9430>] lr : [<c04b5a18>] psr: 800a0313 sp : ee32be14 ip : 000005ea fp : 00000bd4 r10: ee558500 r9 : c0116298 r8 : 00000002 r7 : 00000000 r6 : ef128810 r5 : 0199326

    Veröffentlicht Aktualisiert
  7. CVE-2022-50055

    Mittel · CVSS 5.5EPSS 0,19%Keine Korrektur veröffentlicht

    iavf: Fix adminq error handling

    In the Linux kernel, the following vulnerability has been resolved: iavf: Fix adminq error handling iavf_alloc_asq_bufs/iavf_alloc_arq_bufs allocates with dma_alloc_coherent memory for VF mailbox. Free DMA regions for both ASQ and ARQ in case error happens during configuration of ASQ/ARQ registers. Without this change it is possible to see when unloading interface: 74626.583369: dma_debug_device_change: device driver has pending DMA allocations while released from device [count=32] One of leaked entries details: [device address=0x0000000b27ff9000] [size=4096 bytes] [mapped with DMA_BIDIRECTIONAL] [mapped as coherent]

    Veröffentlicht Aktualisiert
  8. CVE-2022-50053

    Mittel · CVSS 5.6EPSS 0,14%Keine Korrektur veröffentlicht

    iavf: Fix reset error handling

    In the Linux kernel, the following vulnerability has been resolved: iavf: Fix reset error handling Do not call iavf_close in iavf_reset_task error handling. Doing so can lead to double call of napi_disable, which can lead to deadlock there. Removing VF would lead to iavf_remove task being stuck, because it requires crit_lock, which is held by iavf_close. Call iavf_disable_vf if reset fail, so that driver will clean up remaining invalid resources. During rapid VF resets, HW can fail to setup VF mailbox. Wrong error handling can lead to iavf_remove being stuck with: [ 5218.999087] iavf 0000:82:01.0: Failed to init adminq: -53 ... [ 5267.18921

    Veröffentlicht Aktualisiert
  9. CVE-2022-50047

    Mittel · CVSS 5.5EPSS 0,19%Keine Korrektur veröffentlicht

    net: dsa: mv88e6060: prevent crash on an unused port

    In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6060: prevent crash on an unused port If the port isn't a CPU port nor a user port, 'cpu_dp' is a null pointer and a crash happened on dereferencing it in mv88e6060_setup_port(): [ 9.575872] Unable to handle kernel NULL pointer dereference at virtual address 00000014 ... [ 9.942216] mv88e6060_setup from dsa_register_switch+0x814/0xe84 [ 9.948616] dsa_register_switch from mdio_probe+0x2c/0x54 [ 9.954433] mdio_probe from really_probe.part.0+0x98/0x2a0 [ 9.960375] really_probe.part.0 from driver_probe_device+0x30/0x10c [ 9.967029] driver_

    Veröffentlicht Aktualisiert
  10. CVE-2022-50030

    Hoch · CVSS 7.8EPSS 0,22%Keine Korrektur veröffentlicht

    scsi: lpfc: Prevent buffer overflow crashes in debugfs with malformed user input

    In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Prevent buffer overflow crashes in debugfs with malformed user input Malformed user input to debugfs results in buffer overflow crashes. Adapt input string lengths to fit within internal buffers, leaving space for NULL terminators.

    Veröffentlicht Aktualisiert
  11. CVE-2022-50021

    Hoch · CVSS 7.8EPSS 0,2%Keine Korrektur veröffentlicht

    ext4: block range must be validated before use in ext4_mb_clear_bb()

    In the Linux kernel, the following vulnerability has been resolved: ext4: block range must be validated before use in ext4_mb_clear_bb() Block range to free is validated in ext4_free_blocks() using ext4_inode_block_valid() and then it's passed to ext4_mb_clear_bb(). However in some situations on bigalloc file system the range might be adjusted after the validation in ext4_free_blocks() which can lead to troubles on corrupted file systems such as one found by syzkaller that resulted in the following BUG kernel BUG at fs/ext4/ext4.h:3319! PREEMPT SMP NOPTI CPU: 28 PID: 4243 Comm: repro Kdump: loaded Not tainted 5.19.0-rc6+ #1 Hardware name:

    Veröffentlicht Aktualisiert
  12. CVE-2022-50013

    Mittel · CVSS 6EPSS 0,25%Keine Korrektur veröffentlicht

    f2fs: fix to avoid use f2fs_bug_on() in f2fs_new_node_page()

    In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use f2fs_bug_on() in f2fs_new_node_page() As Dipanjan Das <[email protected]> reported, syzkaller found a f2fs bug as below: RIP: 0010:f2fs_new_node_page+0x19ac/0x1fc0 fs/f2fs/node.c:1295 Call Trace: write_all_xattrs fs/f2fs/xattr.c:487 [inline] __f2fs_setxattr+0xe76/0x2e10 fs/f2fs/xattr.c:743 f2fs_setxattr+0x233/0xab0 fs/f2fs/xattr.c:790 f2fs_xattr_generic_set+0x133/0x170 fs/f2fs/xattr.c:86 __vfs_setxattr+0x115/0x180 fs/xattr.c:182 __vfs_setxattr_noperm+0x125/0x5f0 fs/xattr.c:216 __vfs_setxattr_locked+0x1cf/0x260 fs/xattr.c:277 vfs_set

    Veröffentlicht Aktualisiert
  13. CVE-2022-49998

    Hoch · CVSS 7.8EPSS 0,2%Keine Korrektur veröffentlicht

    rxrpc: Fix locking in rxrpc's sendmsg

    In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix locking in rxrpc's sendmsg Fix three bugs in the rxrpc's sendmsg implementation: (1) rxrpc_new_client_call() should release the socket lock when returning an error from rxrpc_get_call_slot(). (2) rxrpc_wait_for_tx_window_intr() will return without the call mutex held in the event that we're interrupted by a signal whilst waiting for tx space on the socket or relocking the call mutex afterwards. Fix this by: (a) moving the unlock/lock of the call mutex up to rxrpc_send_data() such that the lock is not held around all of rxrpc_wai

    Veröffentlicht Aktualisiert
  14. CVE-2022-49989

    Mittel · CVSS 5.5EPSS 0,25%Keine Korrektur veröffentlicht

    xen/privcmd: fix error exit of privcmd_ioctl_dm_op()

    In the Linux kernel, the following vulnerability has been resolved: xen/privcmd: fix error exit of privcmd_ioctl_dm_op() The error exit of privcmd_ioctl_dm_op() is calling unlock_pages() potentially with pages being NULL, leading to a NULL dereference. Additionally lock_pages() doesn't check for pin_user_pages_fast() having been completely successful, resulting in potentially not locking all pages into memory. This could result in sporadic failures when using the related memory in user mode. Fix all of that by calling unlock_pages() always with the real number of pinned pages, which will be zero in case pages being NULL, and by checking t

    Veröffentlicht Aktualisiert
  15. CVE-2022-49980

    Hoch · CVSS 7.8EPSS 0,24%Keine Korrektur veröffentlicht

    USB: gadget: Fix use-after-free Read in usb_udc_uevent()

    In the Linux kernel, the following vulnerability has been resolved: USB: gadget: Fix use-after-free Read in usb_udc_uevent() The syzbot fuzzer found a race between uevent callbacks and gadget driver unregistration that can cause a use-after-free bug: --------------------------------------------------------------- BUG: KASAN: use-after-free in usb_udc_uevent+0x11f/0x130 drivers/usb/gadget/udc/core.c:1732 Read of size 8 at addr ffff888078ce2050 by task udevd/2968 CPU: 1 PID: 2968 Comm: udevd Not tainted 5.19.0-rc4-next-20220628-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/29/2022 Call Trace:

    Veröffentlicht Aktualisiert
  16. CVE-2022-49975

    Hoch · CVSS 7.8EPSS 0,27%Keine Korrektur veröffentlicht

    bpf: Don't redirect packets with invalid pkt_len

    In the Linux kernel, the following vulnerability has been resolved: bpf: Don't redirect packets with invalid pkt_len Syzbot found an issue [1]: fq_codel_drop() try to drop a flow whitout any skbs, that is, the flow->head is null. The root cause, as the [2] says, is because that bpf_prog_test_run_skb() run a bpf prog which redirects empty skbs. So we should determine whether the length of the packet modified by bpf prog or others like bpf_prog_test is valid before forwarding it directly.

    Veröffentlicht Aktualisiert
  17. CVE-2022-49969

    Hoch · CVSS 7.8EPSS 0,29%Keine Korrektur veröffentlicht

    drm/amd/display: clear optc underflow before turn off odm clock

    In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: clear optc underflow before turn off odm clock [Why] After ODM clock off, optc underflow bit will be kept there always and clear not work. We need to clear that before clock off. [How] Clear that if have when clock off.

    Veröffentlicht Aktualisiert
  18. CVE-2022-49967

    Mittel · CVSS 4.7EPSS 0,14%Keine Korrektur veröffentlicht

    bpf: Fix a data-race around bpf_jit_limit.

    In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a data-race around bpf_jit_limit. While reading bpf_jit_limit, it can be changed concurrently via sysctl, WRITE_ONCE() in __do_proc_doulongvec_minmax(). The size of bpf_jit_limit is long, so we need to add a paired READ_ONCE() to avoid load-tearing.

    Veröffentlicht Aktualisiert
  19. CVE-2022-49954

    Mittel · CVSS 5.5EPSS 0,25%Keine Korrektur veröffentlicht

    Input: iforce - wake up after clearing IFORCE_XMIT_RUNNING flag

    In the Linux kernel, the following vulnerability has been resolved: Input: iforce - wake up after clearing IFORCE_XMIT_RUNNING flag syzbot is reporting hung task at __input_unregister_device() [1], for iforce_close() waiting at wait_event_interruptible() with dev->mutex held is blocking input_disconnect_device() from __input_unregister_device(). It seems that the cause is simply that commit c2b27ef672992a20 ("Input: iforce - wait for command completion when closing the device") forgot to call wake_up() after clear_bit(). Fix this problem by introducing a helper that calls clear_bit() followed by wake_up_all().

    Veröffentlicht Aktualisiert
  20. CVE-2022-49940

    Mittel · CVSS 6.8EPSS 0,23%Keine Korrektur veröffentlicht

    tty: n_gsm: add sanity check for gsm->receive in gsm_receive_buf()

    In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: add sanity check for gsm->receive in gsm_receive_buf() A null pointer dereference can happen when attempting to access the "gsm->receive()" function in gsmld_receive_buf(). Currently, the code assumes that gsm->recieve is only called after MUX activation. Since the gsmld_receive_buf() function can be accessed without the need to initialize the MUX, the gsm->receive() function will not be set and a NULL pointer dereference will occur. Fix this by avoiding the call to "gsm->receive()" in case the function is not initialized by adding a sanity check. Call Trace:

    Veröffentlicht Aktualisiert

Prüfen Sie Ihren Server

Gleichen Sie Ihren installierten Stack und seine Versionen mit den aktuellen Sicherheitsmeldungen ab.

Prüfen Sie Ihren Server →