p PatchFirst

PatchFirst · Свежие уязвимости

Уязвимости linux · Страница 192

За последние 30 дней в linux опубликовано уязвимостей: 269; в каталоге KEV: 0.

Фильтры уязвимостей
Сбросить фильтры

Уязвимостей: 5080

  1. CVE-2024-47659

    Критический · CVSS 9.1EPSS 0,78%Есть исправление

    smack: tcp: ipv4, fix incorrect labeling

    In the Linux kernel, the following vulnerability has been resolved: smack: tcp: ipv4, fix incorrect labeling Currently, Smack mirrors the label of incoming tcp/ipv4 connections: when a label 'foo' connects to a label 'bar' with tcp/ipv4, 'foo' always gets 'foo' in returned ipv4 packets. So, 1) returned packets are incorrectly labeled ('foo' instead of 'bar') 2) 'bar' can write to 'foo' without being authorized to write. Here is a scenario how to see this: * Take two machines, let's call them C and S, with active Smack in the default state (no settings, no rules, no labeled hosts, only builtin labels) * At S, add Smack rule 'foo bar

    • Обновитесь до 4.4.0-278.312
    Опубликовано Обновлено
  2. CVE-2024-46859

    Высокий · CVSS 7.8EPSS 0,22%Нет опубликованного исправления

    platform/x86: panasonic-laptop: Fix SINF array out of bounds accesses

    In the Linux kernel, the following vulnerability has been resolved: platform/x86: panasonic-laptop: Fix SINF array out of bounds accesses The panasonic laptop code in various places uses the SINF array with index values of 0 - SINF_CUR_BRIGHT(0x0d) without checking that the SINF array is big enough. Not all panasonic laptops have this many SINF array entries, for example the Toughbook CF-18 model only has 10 SINF array entries. So it only supports the AC+DC brightness entries and mute. Check that the SINF array has a minimum size which covers all AC+DC brightness entries and refuse to load if the SINF array is smaller. For higher SINF in

    Опубликовано Обновлено
  3. CVE-2024-46848

    Средний · CVSS 6.8EPSS 0,22%Нет опубликованного исправления

    perf/x86/intel: Limit the period on Haswell

    In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Limit the period on Haswell Running the ltp test cve-2015-3290 concurrently reports the following warnings. perfevents: irq loop stuck! WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174 intel_pmu_handle_irq+0x285/0x370 Call Trace: <NMI> ? __warn+0xa4/0x220 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? report_bug+0x3e/0xa0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op

    Опубликовано Обновлено
  4. CVE-2024-46844

    Высокий · CVSS 7.1EPSS 0,26%Нет опубликованного исправления

    um: line: always fill *error_out in setup_one_line()

    In the Linux kernel, the following vulnerability has been resolved: um: line: always fill *error_out in setup_one_line() The pointer isn't initialized by callers, but I have encountered cases where it's still printed; initialize it in all possible cases in setup_one_line().

    Опубликовано Обновлено
  5. CVE-2024-46841

    Средний · CVSS 5.7EPSS 0,24%Нет опубликованного исправления

    btrfs: don't BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc()

    In the Linux kernel, the following vulnerability has been resolved: btrfs: don't BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc() We handle errors here properly, ENOMEM isn't fatal, return the error.

    Опубликовано Обновлено
  6. CVE-2024-46840

    Высокий · CVSS 7.1EPSS 0,26%Нет опубликованного исправления

    btrfs: clean up our handling of refs == 0 in snapshot delete

    In the Linux kernel, the following vulnerability has been resolved: btrfs: clean up our handling of refs == 0 in snapshot delete In reada we BUG_ON(refs == 0), which could be unkind since we aren't holding a lock on the extent leaf and thus could get a transient incorrect answer. In walk_down_proc we also BUG_ON(refs == 0), which could happen if we have extent tree corruption. Change that to return -EUCLEAN. In do_walk_down() we catch this case and handle it correctly, however we return -EIO, which -EUCLEAN is a more appropriate error code. Finally in walk_up_proc we have the same BUG_ON(refs == 0), so convert that to proper error handli

    Опубликовано Обновлено
  7. CVE-2024-46834

    Высокий · CVSS 7.8EPSS 0,29%Нет опубликованного исправления

    ethtool: fail closed if we can't get max channel used in indirection tables

    In the Linux kernel, the following vulnerability has been resolved: ethtool: fail closed if we can't get max channel used in indirection tables Commit 0d1b7d6c9274 ("bnxt: fix crashes when reducing ring count with active RSS contexts") proves that allowing indirection table to contain channels with out of bounds IDs may lead to crashes. Currently the max channel check in the core gets skipped if driver can't fetch the indirection table or when we can't allocate memory. Both of those conditions should be extremely rare but if they do happen we should try to be safe and fail the channel change.

    Опубликовано Обновлено
  8. CVE-2024-46832

    Средний · CVSS 5.5EPSS 0,24%Нет опубликованного исправления

    MIPS: cevt-r4k: Don't call get_c0_compare_int if timer irq is installed

    In the Linux kernel, the following vulnerability has been resolved: MIPS: cevt-r4k: Don't call get_c0_compare_int if timer irq is installed This avoids warning: [ 0.118053] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283 Caused by get_c0_compare_int on secondary CPU. We also skipped saving IRQ number to struct clock_event_device *cd as it's never used by clockevent core, as per comments it's only meant for "non CPU local devices".

    Опубликовано Обновлено
  9. CVE-2024-46829

    Средний · CVSS 5.5EPSS 0,2%Нет опубликованного исправления

    rtmutex: Drop rt_mutex::wait_lock before scheduling

    In the Linux kernel, the following vulnerability has been resolved: rtmutex: Drop rt_mutex::wait_lock before scheduling rt_mutex_handle_deadlock() is called with rt_mutex::wait_lock held. In the good case it returns with the lock held and in the deadlock case it emits a warning and goes into an endless scheduling loop with the lock held, which triggers the 'scheduling in atomic' warning. Unlock rt_mutex::wait_lock in the dead lock case before issuing the warning and dropping into the schedule for ever loop. [ tglx: Moved unlock before the WARN(), removed the pointless comment, massaged changelog, added Fixes tag ]

    Опубликовано Обновлено
  10. CVE-2024-46826

    Средний · CVSS 5.5EPSS 0,25%Есть исправление

    ELF: fix kernel.randomize_va_space double read

    In the Linux kernel, the following vulnerability has been resolved: ELF: fix kernel.randomize_va_space double read ELF loader uses "randomize_va_space" twice. It is sysctl and can change at any moment, so 2 loads could see 2 different values in theory with unpredictable consequences. Issue exactly one load for consistent value across one exec.

    • Обновитесь до 4.4.0-267.301
    Опубликовано Обновлено
  11. CVE-2024-46822

    Средний · CVSS 5.5EPSS 0,25%Нет опубликованного исправления

    arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry

    In the Linux kernel, the following vulnerability has been resolved: arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry In a review discussion of the changes to support vCPU hotplug where a check was added on the GICC being enabled if was online, it was noted that there is need to map back to the cpu and use that to index into a cpumask. As such, a valid ID is needed. If an MPIDR check fails in acpi_map_gic_cpu_interface() it is possible for the entry in cpu_madt_gicc[cpu] == NULL. This function would then cause a NULL pointer dereference. Whilst a path to trigger this has not been established, harden this caller against

    Опубликовано Обновлено
  12. CVE-2022-48945

    Высокий · CVSS 7.8EPSS 0,22%Нет опубликованного исправления

    media: vivid: fix compose size exceed boundary

    In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix compose size exceed boundary syzkaller found a bug: BUG: unable to handle page fault for address: ffffc9000a3b1000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10015f067 PMD 1121ca067 PTE 0 Oops: 0002 [#1] PREEMPT SMP CPU: 0 PID: 23489 Comm: vivid-000-vid-c Not tainted 6.1.0-rc1+ #512 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:memcpy_erms+0x6/0x10 [...] Call Trace: <TASK> ? tpg_fill_plane_buffer+0x856/0x15b0 vivi

    Опубликовано Обновлено
  13. CVE-2024-46800

    Высокий · CVSS 7.8EPSS 0,3%Есть исправление

    sch/netem: fix use after free in netem_dequeue

    In the Linux kernel, the following vulnerability has been resolved: sch/netem: fix use after free in netem_dequeue If netem_dequeue() enqueues packet to inner qdisc and that qdisc returns __NET_XMIT_STOLEN. The packet is dropped but qdisc_tree_reduce_backlog() is not called to update the parent's q.qlen, leading to the similar use-after-free as Commit e04991a48dbaf382 ("netem: fix return value if duplicate enqueue fails") Commands to trigger KASAN UaF: ip link add type dummy ip link set lo up ip link set dummy0 up tc qdisc add dev lo parent root handle 1: drr tc filter add dev lo parent 1: basic classid 1:1 tc class add dev lo classid 1:1

    • Обновитесь до 4.4.0-261.295
    Опубликовано Обновлено
  14. CVE-2024-46787

    Высокий · CVSS 7.8EPSS 0,22%Есть исправление

    userfaultfd: fix checks for huge PMDs

    In the Linux kernel, the following vulnerability has been resolved: userfaultfd: fix checks for huge PMDs Patch series "userfaultfd: fix races around pmd_trans_huge() check", v2. The pmd_trans_huge() code in mfill_atomic() is wrong in three different ways depending on kernel version: 1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit the right two race windows) - I've tested this in a kernel build with some extra mdelay() calls. See the commit message for a description of the race scenario. On older kernels (before 6.5), I think the same bug can even theoretically lead to accessing transhuge page c

    • Обновитесь до 4.4.0-270.304
    Опубликовано Обновлено
  15. CVE-2024-46781

    Высокий · CVSS 7.8EPSS 0,25%Нет опубликованного исправления

    nilfs2: fix missing cleanup on rollforward recovery error

    In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix missing cleanup on rollforward recovery error In an error injection test of a routine for mount-time recovery, KASAN found a use-after-free bug. It turned out that if data recovery was performed using partial logs created by dsync writes, but an error occurred before starting the log writer to create a recovered checkpoint, the inodes whose data had been recovered were left in the ns_dirty_files list of the nilfs object and were not freed. Fix this issue by cleaning up inodes that have read the recovery data if the recovery routine fails midway before the log

    Опубликовано Обновлено
  16. CVE-2024-46780

    Высокий · CVSS 7.8EPSS 0,24%Есть исправление

    nilfs2: protect references to superblock parameters exposed in sysfs

    In the Linux kernel, the following vulnerability has been resolved: nilfs2: protect references to superblock parameters exposed in sysfs The superblock buffers of nilfs2 can not only be overwritten at runtime for modifications/repairs, but they are also regularly swapped, replaced during resizing, and even abandoned when degrading to one side due to backing device issues. So, accessing them requires mutual exclusion using the reader/writer semaphore "nilfs->ns_sem". Some sysfs attribute show methods read this superblock buffer without the necessary mutual exclusion, which can cause problems with pointer dereferencing and memory access, so

    • Обновитесь до 4.4.0-268.302
    Опубликовано Обновлено
  17. CVE-2024-46777

    Высокий · CVSS 7.8EPSS 0,25%Есть исправление

    udf: Avoid excessive partition lengths

    In the Linux kernel, the following vulnerability has been resolved: udf: Avoid excessive partition lengths Avoid mounting filesystems where the partition would overflow the 32-bits used for block number. Also refuse to mount filesystems where the partition length is so large we cannot safely index bits in a block bitmap.

    • Обновитесь до 4.4.0-279.313
    Опубликовано Обновлено

Проверьте свой сервер

Сопоставьте установленный стек и версии со свежими базами уязвимостей.

Проверьте свой сервер →