p PatchFirst

PatchFirst · Vulnérabilités récentes

Vulnérabilités de linux-fips · Page n° 138

Vulnérabilités publiées pour linux-fips au cours des 30 derniers jours : 376. Présentes dans le catalogue KEV : 0.

Filtrer les vulnérabilités
Effacer les filtres

Vulnérabilités : 5540

  1. CVE-2022-50359

    Moyenne · CVSS 5.5EPSS 0,21%Aucun correctif publié

    media: cx88: Fix a null-ptr-deref bug in buffer_prepare()

    In the Linux kernel, the following vulnerability has been resolved: media: cx88: Fix a null-ptr-deref bug in buffer_prepare() When the driver calls cx88_risc_buffer() to prepare the buffer, the function call may fail, resulting in a empty buffer and null-ptr-deref later in buffer_queue(). The following log can reveal it: [ 41.822762] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI [ 41.824488] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 41.828027] RIP: 0010:buffer_queue+0xc2/0x500 [ 41.836311] Call Trace: [ 41.836945] __enqueue_in_driv

    Publication Mise à jour
  2. CVE-2022-50358

    Moyenne · CVSS 4.2EPSS 0,29%Aucun correctif publié

    brcmfmac: return error when getting invalid max_flowrings from dongle

    In the Linux kernel, the following vulnerability has been resolved: brcmfmac: return error when getting invalid max_flowrings from dongle When firmware hit trap at initialization, host will read abnormal max_flowrings number from dongle, and it will cause kernel panic when doing iowrite to initialize dongle ring. To detect this error at early stage, we directly return error when getting invalid max_flowrings(>256).

    Publication Mise à jour
  3. CVE-2022-50356

    Moyenne · CVSS 5.5EPSS 0,21%Aucun correctif publié

    net: sched: sfb: fix null pointer access issue when sfb_init() fails

    In the Linux kernel, the following vulnerability has been resolved: net: sched: sfb: fix null pointer access issue when sfb_init() fails When the default qdisc is sfb, if the qdisc of dev_queue fails to be inited during mqprio_init(), sfb_reset() is invoked to clear resources. In this case, the q->qdisc is NULL, and it will cause gpf issue. The process is as follows: qdisc_create_dflt() sfb_init() tcf_block_get() --->failed, q->qdisc is NULL ... qdisc_put() ... sfb_reset() qdisc_reset(q->qdisc) --->q->qdisc is NULL ops = qdisc->ops The following is the Call Trace information: general protection fault, probably

    Publication Mise à jour
  4. CVE-2022-50353

    Moyenne · CVSS 5.5EPSS 0,2%Aucun correctif publié

    mmc: wmt-sdmmc: fix return value check of mmc_add_host()

    In the Linux kernel, the following vulnerability has been resolved: mmc: wmt-sdmmc: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and goto error path which will call mmc_free_host(), besides, clk_disable_unprepare() also needs be called.

    Publication Mise à jour
  5. CVE-2023-53333

    Élevée · CVSS 8.2EPSS 0,28%Correctif disponible

    netfilter: conntrack: dccp: copy entire header to stack buffer, not just basic one

    In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: dccp: copy entire header to stack buffer, not just basic one Eric Dumazet says: nf_conntrack_dccp_packet() has an unique: dh = skb_header_pointer(skb, dataoff, sizeof(_dh), &_dh); And nothing more is 'pulled' from the packet, depending on the content. dh->dccph_doff, and/or dh->dccph_x ...) So dccp_ack_seq() is happily reading stuff past the _dh buffer. BUG: KASAN: stack-out-of-bounds in nf_conntrack_dccp_packet+0x1134/0x11c0 Read of size 4 at addr ffff000128f66e0c by task syz-executor.2/29371 [..] Fix this by increasing the stack buffer

    • Mettez à jour vers 4.4.0-1099.106
    Publication Mise à jour
  6. CVE-2023-53331

    Élevée · CVSS 7.8EPSS 0,16%Aucun correctif publié

    pstore/ram: Check start of empty przs during init

    In the Linux kernel, the following vulnerability has been resolved: pstore/ram: Check start of empty przs during init After commit 30696378f68a ("pstore/ram: Do not treat empty buffers as valid"), initialization would assume a prz was valid after seeing that the buffer_size is zero (regardless of the buffer start position). This unchecked start value means it could be outside the bounds of the buffer, leading to future access panics when written to: sysdump_panic_event+0x3b4/0x5b8 atomic_notifier_call_chain+0x54/0x90 panic+0x1c8/0x42c die+0x29c/0x2a8 die_kernel_fault+0x68/0x78 __do_kernel_fault+0x1c4/0x1e0 do_bad_area+0x40/0x100 do

    Publication Mise à jour
  7. CVE-2023-53330

    Moyenne · CVSS 5.5EPSS 0,15%Aucun correctif publié

    caif: fix memory leak in cfctrl_linkup_request()

    In the Linux kernel, the following vulnerability has been resolved: caif: fix memory leak in cfctrl_linkup_request() When linktype is unknown or kzalloc failed in cfctrl_linkup_request(), pkt is not released. Add release process to error path.

    Publication Mise à jour
  8. CVE-2023-53322

    Élevée · CVSS 8.8EPSS 0,21%Aucun correctif publié

    scsi: qla2xxx: Wait for io return on terminate rport

    In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Wait for io return on terminate rport System crash due to use after free. Current code allows terminate_rport_io to exit before making sure all IOs has returned. For FCP-2 device, IO's can hang on in HW because driver has not tear down the session in FW at first sign of cable pull. When dev_loss_tmo timer pops, terminate_rport_io is called and upper layer is about to free various resources. Terminate_rport_io trigger qla to do the final cleanup, but the cleanup might not be fast enough where it leave qla still holding on to the same resource. Wait for IO's t

    Publication Mise à jour
  9. CVE-2023-53317

    Moyenne · CVSS 5.5EPSS 0,16%Aucun correctif publié

    ext4: fix WARNING in mb_find_extent

    In the Linux kernel, the following vulnerability has been resolved: ext4: fix WARNING in mb_find_extent Syzbot found the following issue: EXT4-fs: Warning: mounting with data=journal disables delayed allocation, dioread_nolock, O_DIRECT and fast_commit support! EXT4-fs (loop0): orphan cleanup on readonly fs ------------[ cut here ]------------ WARNING: CPU: 1 PID: 5067 at fs/ext4/mballoc.c:1869 mb_find_extent+0x8a1/0xe30 Modules linked in: CPU: 1 PID: 5067 Comm: syz-executor307 Not tainted 6.2.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 RIP: 0010:mb_find_extent+0x8a1/0xe30 fs

    Publication Mise à jour
  10. CVE-2023-53314

    Élevée · CVSS 7.8EPSS 0,17%Aucun correctif publié

    fbdev/ep93xx-fb: Do not assign to struct fb_info.dev

    In the Linux kernel, the following vulnerability has been resolved: fbdev/ep93xx-fb: Do not assign to struct fb_info.dev Do not assing the Linux device to struct fb_info.dev. The call to register_framebuffer() initializes the field to the fbdev device. Drivers should not override its value. Fixes a bug where the driver incorrectly decreases the hardware device's reference counter and leaks the fbdev device. v2: * add Fixes tag (Dan)

    Publication Mise à jour
  11. CVE-2023-53311

    Élevée · CVSS 7.8EPSS 0,16%Aucun correctif publié

    nilfs2: fix use-after-free of nilfs_root in dirtying inodes via iput

    In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix use-after-free of nilfs_root in dirtying inodes via iput During unmount process of nilfs2, nothing holds nilfs_root structure after nilfs2 detaches its writer in nilfs_detach_log_writer(). Previously, nilfs_evict_inode() could cause use-after-free read for nilfs_root if inodes are left in "garbage_list" and released by nilfs_dispose_list at the end of nilfs_detach_log_writer(), and this bug was fixed by commit 9b5a04ac3ad9 ("nilfs2: fix use-after-free bug of nilfs_root in nilfs_evict_inode()"). However, it turned out that there is another possibility of UAF in

    Publication Mise à jour
  12. CVE-2023-53309

    Moyenne · CVSS 5.5EPSS 0,16%Aucun correctif publié

    drm/radeon: Fix integer overflow in radeon_cs_parser_init

    In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix integer overflow in radeon_cs_parser_init The type of size is unsigned, if size is 0x40000000, there will be an integer overflow, size will be zero after size *= sizeof(uint32_t), will cause uninitialized memory to be referenced later

    Publication Mise à jour
  13. CVE-2022-50352

    Moyenne · CVSS 5.5EPSS 0,16%Aucun correctif publié

    net: hns: fix possible memory leak in hnae_ae_register()

    In the Linux kernel, the following vulnerability has been resolved: net: hns: fix possible memory leak in hnae_ae_register() 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 freed in callback function kobject_cleanup(). unreferenced object 0xffff00c01aba2100 (size 128): comm "systemd-udevd", pid 1259, jiffies 4294903284 (age 294.152s) hex dump (first 32 bytes): 68 6e 61 65 30 00 00 00 18 21 ba 1a c0 00 ff ff hnae0....!...... 00 00 00 00 00 00 00 00 00 00 00 00 00

    Publication Mise à jour
  14. CVE-2022-50350

    Critique · CVSS 9.8EPSS 0,27%Aucun correctif publié

    scsi: target: iscsi: Fix a race condition between login_work and the login thread

    In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix a race condition between login_work and the login thread In case a malicious initiator sends some random data immediately after a login PDU; the iscsi_target_sk_data_ready() callback will schedule the login_work and, at the same time, the negotiation may end without clearing the LOGIN_FLAGS_INITIAL_PDU flag (because no additional PDU exchanges are required to complete the login). The login has been completed but the login_work function will find the LOGIN_FLAGS_INITIAL_PDU flag set and will never stop from rescheduling itself; at this point, if the

    Publication Mise à jour
  15. CVE-2022-50349

    Moyenne · CVSS 5.5EPSS 0,16%Aucun correctif publié

    misc: tifm: fix possible memory leak in tifm_7xx1_switch_media()

    In the Linux kernel, the following vulnerability has been resolved: misc: tifm: fix possible memory leak in tifm_7xx1_switch_media() If device_register() returns error in tifm_7xx1_switch_media(), name of kobject which is allocated in dev_set_name() called in device_add() is leaked. Never directly free @dev after calling device_register(), even if it returned an error! Always use put_device() to give up the reference initialized.

    Publication Mise à jour
  16. CVE-2022-50347

    Moyenne · CVSS 5.5EPSS 0,16%Aucun correctif publié

    mmc: rtsx_usb_sdmmc: fix return value check of mmc_add_host()

    In the Linux kernel, the following vulnerability has been resolved: mmc: rtsx_usb_sdmmc: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and calling mmc_free_host() in the error path, besides, led_classdev_unregister() and pm_runtime_disable() also need be called.

    Publication Mise à jour
  17. CVE-2022-50346

    Moyenne · CVSS 5.5EPSS 0,16%Aucun correctif publié

    ext4: init quota for 'old.inode' in 'ext4_rename'

    In the Linux kernel, the following vulnerability has been resolved: ext4: init quota for 'old.inode' in 'ext4_rename' Syzbot found the following issue: ext4_parse_param: s_want_extra_isize=128 ext4_inode_info_init: s_want_extra_isize=32 ext4_rename: old.inode=ffff88823869a2c8 old.dir=ffff888238699828 new.inode=ffff88823869d7e8 new.dir=ffff888238699828 __ext4_mark_inode_dirty: inode=ffff888238699828 ea_isize=32 want_ea_size=128 __ext4_mark_inode_dirty: inode=ffff88823869a2c8 ea_isize=32 want_ea_size=128 ext4_xattr_block_set: inode=ffff88823869a2c8 ------------[ cut here ]------------ WARNING: CPU: 13 PID: 2234 at fs/ext4/xattr.c:2070 ext4_xa

    Publication Mise à jour

Vérifiez votre serveur

Comparez votre pile et les versions installées aux bases de vulnérabilités actuelles.

Vérifiez votre serveur →