p PatchFirst

PatchFirst · Vulnérabilités récentes

Vulnérabilités de linux-intel-iotg-5.15 · Page n° 195

Vulnérabilité publiée pour linux-intel-iotg-5.15 au cours des 30 derniers jours : 0. Dans le catalogue KEV : 0.

Filtrer les vulnérabilités
Effacer les filtres

Vulnérabilités : 4693

  1. CVE-2022-48657

    Élevée · CVSS 7.8EPSS 0,25%Correctif disponible

    arm64: topology: fix possible overflow in amu_fie_setup()

    In the Linux kernel, the following vulnerability has been resolved: arm64: topology: fix possible overflow in amu_fie_setup() cpufreq_get_hw_max_freq() returns max frequency in kHz as *unsigned int*, while freq_inv_set_max_ratio() gets passed this frequency in Hz as 'u64'. Multiplying max frequency by 1000 can potentially result in overflow -- multiplying by 1000ULL instead should avoid that... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.

    • Mettez à jour vers 5.15.0-1023.28~20.04.1
    Publication Mise à jour
  2. CVE-2022-48656

    Moyenne · CVSS 5.5EPSS 0,26%Correctif disponible

    dmaengine: ti: k3-udma-private: Fix refcount leak bug in of_xudma_dev_get()

    In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: k3-udma-private: Fix refcount leak bug in of_xudma_dev_get() We should call of_node_put() for the reference returned by of_parse_phandle() in fail path or when it is not used anymore. Here we only need to move the of_node_put() before the check.

    • Mettez à jour vers 5.15.0-1023.28~20.04.1
    Publication Mise à jour
  3. CVE-2022-48655

    Élevée · CVSS 8.1EPSS 0,74%Correctif disponible

    firmware: arm_scmi: Harden accesses to the reset domains

    In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Harden accesses to the reset domains Accessing reset domains descriptors by the index upon the SCMI drivers requests through the SCMI reset operations interface can potentially lead to out-of-bound violations if the SCMI driver misbehave. Add an internal consistency check before any such domains descriptors accesses.

    • Mettez à jour vers 5.15.0-1023.28~20.04.1
    Publication Mise à jour
  4. CVE-2022-48654

    Élevée · CVSS 7.1EPSS 0,25%Correctif disponible

    netfilter: nfnetlink_osf: fix possible bogus match in nf_osf_find()

    In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_osf: fix possible bogus match in nf_osf_find() nf_osf_find() incorrectly returns true on mismatch, this leads to copying uninitialized memory area in nft_osf which can be used to leak stale kernel stack data to userspace.

    • Mettez à jour vers 5.15.0-1023.28~20.04.1
    Publication Mise à jour
  5. CVE-2022-48653

    Moyenne · CVSS 5.5EPSS 0,23%Correctif disponible

    ice: Don't double unplug aux on peer initiated reset

    In the Linux kernel, the following vulnerability has been resolved: ice: Don't double unplug aux on peer initiated reset In the IDC callback that is accessed when the aux drivers request a reset, the function to unplug the aux devices is called. This function is also called in the ice_prepare_for_reset function. This double call is causing a "scheduling while atomic" BUG. [ 662.676430] ice 0000:4c:00.0 rocep76s0: cqp opcode = 0x1 maj_err_code = 0xffff min_err_code = 0x8003 [ 662.676609] ice 0000:4c:00.0 rocep76s0: [Modify QP Cmd Error][op_code=8] status=-29 waiting=1 completion_err=1 maj=0xffff min=0x8003 [ 662.815006] ice 0000:4c:00

    • Mettez à jour vers 5.15.0-1023.28~20.04.1
    Publication Mise à jour
  6. CVE-2022-48651

    Élevée · CVSS 7.7EPSS 0,25%Correctif disponible

    ipvlan: Fix out-of-bound bugs caused by unset skb->mac_header

    In the Linux kernel, the following vulnerability has been resolved: ipvlan: Fix out-of-bound bugs caused by unset skb->mac_header If an AF_PACKET socket is used to send packets through ipvlan and the default xmit function of the AF_PACKET socket is changed from dev_queue_xmit() to packet_direct_xmit() via setsockopt() with the option name of PACKET_QDISC_BYPASS, the skb->mac_header may not be reset and remains as the initial value of 65535, this may trigger slab-out-of-bounds bugs as following: ================================================================= UG: KASAN: slab-out-of-bounds in ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan] PU: 2 PI

    • Mettez à jour vers 5.15.0-1023.28~20.04.1
    Publication Mise à jour
  7. CVE-2022-48650

    Moyenne · CVSS 4.7EPSS 0,23%Correctif disponible

    scsi: qla2xxx: Fix memory leak in __qlt_24xx_handle_abts()

    In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix memory leak in __qlt_24xx_handle_abts() Commit 8f394da36a36 ("scsi: qla2xxx: Drop TARGET_SCF_LOOKUP_LUN_FROM_TAG") made the __qlt_24xx_handle_abts() function return early if tcm_qla2xxx_find_cmd_by_tag() didn't find a command, but it missed to clean up the allocated memory for the management command.

    • Mettez à jour vers 5.15.0-1023.28~20.04.1
    Publication Mise à jour
  8. CVE-2022-48648

    Moyenne · CVSS 5.5EPSS 0,23%Correctif disponible

    sfc: fix null pointer dereference in efx_hard_start_xmit

    In the Linux kernel, the following vulnerability has been resolved: sfc: fix null pointer dereference in efx_hard_start_xmit Trying to get the channel from the tx_queue variable here is wrong because we can only be here if tx_queue is NULL, so we shouldn't dereference it. As the above comment in the code says, this is very unlikely to happen, but it's wrong anyway so let's fix it. I hit this issue because of a different bug that caused tx_queue to be NULL. If that happens, this is the error message that we get here: BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [...] RIP: 0010:efx_hard_start_xmit+0x153/0x1

    • Mettez à jour vers 5.15.0-1023.28~20.04.1
    Publication Mise à jour
  9. CVE-2022-48647

    Moyenne · CVSS 5.5EPSS 0,23%Correctif disponible

    sfc: fix TX channel offset when using legacy interrupts

    In the Linux kernel, the following vulnerability has been resolved: sfc: fix TX channel offset when using legacy interrupts In legacy interrupt mode the tx_channel_offset was hardcoded to 1, but that's not correct if efx_sepparate_tx_channels is false. In that case, the offset is 0 because the tx queues are in the single existing channel at index 0, together with the rx queue. Without this fix, as soon as you try to send any traffic, it tries to get the tx queues from an uninitialized channel getting these errors: WARNING: CPU: 1 PID: 0 at drivers/net/ethernet/sfc/tx.c:540 efx_hard_start_xmit+0x12e/0x170 [sfc] [...] RIP: 0010:efx_har

    • Mettez à jour vers 5.15.0-1023.28~20.04.1
    Publication Mise à jour
  10. CVE-2022-48645

    Moyenne · CVSS 5.5EPSS 0,22%Correctif disponible

    net: enetc: deny offload of tc-based TSN features on VF interfaces

    In the Linux kernel, the following vulnerability has been resolved: net: enetc: deny offload of tc-based TSN features on VF interfaces TSN features on the ENETC (taprio, cbs, gate, police) are configured through a mix of command BD ring messages and port registers: enetc_port_rd(), enetc_port_wr(). Port registers are a region of the ENETC memory map which are only accessible from the PCIe Physical Function. They are not accessible from the Virtual Functions. Moreover, attempting to access these registers crashes the kernel: $ echo 1 > /sys/bus/pci/devices/0000\:00\:00.0/sriov_numvfs pci 0000:00:01.0: [1957:ef00] type 00 class 0x020001 fs

    • Mettez à jour vers 5.15.0-1023.28~20.04.1
    Publication Mise à jour
  11. CVE-2022-48644

    Moyenne · CVSS 6.7EPSS 0,23%Correctif disponible

    net/sched: taprio: avoid disabling offload when it was never enabled

    In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: avoid disabling offload when it was never enabled In an incredibly strange API design decision, qdisc->destroy() gets called even if qdisc->init() never succeeded, not exclusively since commit 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation"), but apparently also earlier (in the case of qdisc_create_dflt()). The taprio qdisc does not fully acknowledge this when it attempts full offload, because it starts off with q->flags = TAPRIO_FLAGS_INVALID in taprio_init(), then it replaces q->flags with TCA_TAPRIO_ATTR_FLAGS parsed from netlink (in t

    • Mettez à jour vers 5.15.0-1023.28~20.04.1
    Publication Mise à jour
  12. CVE-2022-48643

    Moyenne · CVSS 5.5EPSS 0,23%Correctif disponible

    netfilter: nf_tables: fix nft_counters_enabled underflow at nf_tables_addchain()

    In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix nft_counters_enabled underflow at nf_tables_addchain() syzbot is reporting underflow of nft_counters_enabled counter at nf_tables_addchain() [1], for commit 43eb8949cfdffa76 ("netfilter: nf_tables: do not leave chain stats enabled on error") missed that nf_tables_chain_destroy() after nft_basechain_init() in the error path of nf_tables_addchain() decrements the counter because nft_basechain_init() makes nft_is_base_chain() return true by setting NFT_CHAIN_BASE flag. Increment the counter immediately after returning from nft_basechain_init().

    • Mettez à jour vers 5.15.0-1023.28~20.04.1
    Publication Mise à jour
  13. CVE-2022-48642

    Moyenne · CVSS 6.8EPSS 0,23%Correctif disponible

    netfilter: nf_tables: fix percpu memory leak at nf_tables_addchain()

    In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix percpu memory leak at nf_tables_addchain() It seems to me that percpu memory for chain stats started leaking since commit 3bc158f8d0330f0a ("netfilter: nf_tables: map basechain priority to hardware priority") when nft_chain_offload_priority() returned an error.

    • Mettez à jour vers 5.15.0-1023.28~20.04.1
    Publication Mise à jour
  14. CVE-2022-48641

    Moyenne · CVSS 5.5EPSS 0,24%Correctif disponible

    netfilter: ebtables: fix memory leak when blob is malformed

    In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix memory leak when blob is malformed The bug fix was incomplete, it "replaced" crash with a memory leak. The old code had an assignment to "ret" embedded into the conditional, restore this.

    • Mettez à jour vers 5.15.0-1023.28~20.04.1
    Publication Mise à jour
  15. CVE-2022-48640

    Moyenne · CVSS 5.5EPSS 0,23%Correctif disponible

    bonding: fix NULL deref in bond_rr_gen_slave_id

    In the Linux kernel, the following vulnerability has been resolved: bonding: fix NULL deref in bond_rr_gen_slave_id Fix a NULL dereference of the struct bonding.rr_tx_counter member because if a bond is initially created with an initial mode != zero (Round Robin) the memory required for the counter is never created and when the mode is changed there is never any attempt to verify the memory is allocated upon switching modes. This causes the following Oops on an aarch64 machine: [ 334.686773] Unable to handle kernel paging request at virtual address ffff2c91ac905000 [ 334.694703] Mem abort info: [ 334.697486] ESR = 0x000000

    • Mettez à jour vers 5.15.0-1023.28~20.04.1
    Publication Mise à jour
  16. CVE-2022-48639

    Moyenne · CVSS 6.8EPSS 0,23%Correctif disponible

    net: sched: fix possible refcount leak in tc_new_tfilter()

    In the Linux kernel, the following vulnerability has been resolved: net: sched: fix possible refcount leak in tc_new_tfilter() tfilter_put need to be called to put the refount got by tp->ops->get to avoid possible refcount leak when chain->tmplt_ops != NULL and chain->tmplt_ops != tp->ops.

    • Mettez à jour vers 5.15.0-1023.28~20.04.1
    Publication Mise à jour
  17. CVE-2022-48638

    Moyenne · CVSS 5.3EPSS 0,23%Correctif disponible

    cgroup: cgroup_get_from_id() must check the looked-up kn is a directory

    In the Linux kernel, the following vulnerability has been resolved: cgroup: cgroup_get_from_id() must check the looked-up kn is a directory cgroup has to be one kernfs dir, otherwise kernel panic is caused, especially cgroup id is provide from userspace.

    • Mettez à jour vers 5.15.0-1023.28~20.04.1
    Publication Mise à jour
  18. CVE-2022-48637

    Élevée · CVSS 7.8EPSS 0,23%Correctif disponible

    bnxt: prevent skb UAF after handing over to PTP worker

    In the Linux kernel, the following vulnerability has been resolved: bnxt: prevent skb UAF after handing over to PTP worker When reading the timestamp is required bnxt_tx_int() hands over the ownership of the completed skb to the PTP worker. The skb should not be used afterwards, as the worker may run before the rest of our code and free the skb, leading to a use-after-free. Since dev_kfree_skb_any() accepts NULL make the loss of ownership more obvious and set skb to NULL.

    • Mettez à jour vers 5.15.0-1023.28~20.04.1
    Publication Mise à jour
  19. CVE-2022-48636

    Élevée · CVSS 7.8EPSS 0,24%Correctif disponible

    s390/dasd: fix Oops in dasd_alias_get_start_dev due to missing pavgroup

    In the Linux kernel, the following vulnerability has been resolved: s390/dasd: fix Oops in dasd_alias_get_start_dev due to missing pavgroup Fix Oops in dasd_alias_get_start_dev() function caused by the pavgroup pointer being NULL. The pavgroup pointer is checked on the entrance of the function but without the lcu->lock being held. Therefore there is a race window between dasd_alias_get_start_dev() and _lcu_update() which sets pavgroup to NULL with the lcu->lock held. Fix by checking the pavgroup pointer with lcu->lock held.

    • Mettez à jour vers 5.15.0-1023.28~20.04.1
    Publication Mise à jour
  20. CVE-2022-48635

    Moyenne · CVSS 6.2EPSS 0,23%Correctif disponible

    fsdax: Fix infinite loop in dax_iomap_rw()

    In the Linux kernel, the following vulnerability has been resolved: fsdax: Fix infinite loop in dax_iomap_rw() I got an infinite loop and a WARNING report when executing a tail command in virtiofs. WARNING: CPU: 10 PID: 964 at fs/iomap/iter.c:34 iomap_iter+0x3a2/0x3d0 Modules linked in: CPU: 10 PID: 964 Comm: tail Not tainted 5.19.0-rc7 Call Trace: <TASK> dax_iomap_rw+0xea/0x620 ? __this_cpu_preempt_check+0x13/0x20 fuse_dax_read_iter+0x47/0x80 fuse_file_read_iter+0xae/0xd0 new_sync_read+0xfe/0x180 ? 0xffffffff81000000 vfs_read+0x14d/0x1a0 ksys_read+0x6d/0xf0 __x64_sys_read+0x1a/0x20 do_syscall_64+0x3b/0x90 e

    • Mettez à jour vers 5.15.0-1023.28~20.04.1
    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 →