Page 165 of 2975 results (0.020 seconds)

CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Use access_width over bit_width for system memory accesses To align with ACPI 6.3+, since bit_width can be any 8-bit value, it cannot be depended on to be always on a clean 8b boundary. This was uncovered on the Cobalt 100 platform. SError Interrupt on CPU26, code 0xbe000011 -- SError CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--) pc : cppc_get_perf_caps+0xec/0x410 lr : cppc_get_perf_caps+0xe8/0x410 sp : ffff8000155ab730 x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078 x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000 x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008 x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006 x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028 x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000 Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION Call trace: dump_backtrace+0x0/0x1e0 show_stack+0x24/0x30 dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 panic+0x16c/0x384 add_taint+0x0/0xc0 arm64_serror_panic+0x7c/0x90 arm64_is_fatal_ras_serror+0x34/0xa4 do_serror+0x50/0x6c el1h_64_error_handler+0x40/0x74 el1h_64_error+0x7c/0x80 cppc_get_perf_caps+0xec/0x410 cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq] cpufreq_online+0x2dc/0xa30 cpufreq_add_dev+0xc0/0xd4 subsys_interface_register+0x134/0x14c cpufreq_register_driver+0x1b0/0x354 cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq] do_one_initcall+0x50/0x250 do_init_module+0x60/0x27c load_module+0x2300/0x2570 __do_sys_finit_module+0xa8/0x114 __arm64_sys_finit_module+0x2c/0x3c invoke_syscall+0x78/0x100 el0_svc_common.constprop.0+0x180/0x1a0 do_el0_svc+0x84/0xa0 el0_svc+0x2c/0xc0 el0t_64_sync_handler+0xa4/0x12c el0t_64_sync+0x1a4/0x1a8 Instead, use access_width to determine the size and use the offset and width to shift and mask the bits to read/write out. Make sure to add a check for system memory since pcc redefines the access_width to subspace id. If access_width is not set, then fall back to using bit_width. [ rjw: Subject and changelog edits, comment adjustments ] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: CPPC: use access_width sobre bit_width para accesos a la memoria del sistema. Para alinearse con ACPI 6.3+, dado que bit_width puede ser cualquier valor de 8 bits, no se puede depender de que esté siempre encendido. un límite limpio de 8b. Esto fue descubierto en la plataforma Cobalt 100. • https://git.kernel.org/stable/c/4949affd5288b867cdf115f5b08d6166b2027f87 https://git.kernel.org/stable/c/b54c4632946ae42f2b39ed38abd909bbf78cbcc2 https://git.kernel.org/stable/c/6dfd79ed04c578f1d9a9a41ba5b2015cf9f03fc3 https://git.kernel.org/stable/c/01fc53be672acae37e611c80cc0b4f3939584de3 https://git.kernel.org/stable/c/1b890ae474d19800a6be1696df7fb4d9a41676e4 https://git.kernel.org/stable/c/6cb6b12b78dcd8867a3fdbb1b6d0ed1df2b208d1 https://git.kernel.org/stable/c/2f4a4d63a193be6fd530d180bb13c3592052904c https://access.redhat.com/security/cve/CVE-2024-35995 •

CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr Although ipv6_get_ifaddr walks inet6_addr_lst under the RCU lock, it still means hlist_for_each_entry_rcu can return an item that got removed from the list. The memory itself of such item is not freed thanks to RCU but nothing guarantees the actual content of the memory is sane. In particular, the reference count can be zero. This can happen if ipv6_del_addr is called in parallel. ipv6_del_addr removes the entry from inet6_addr_lst (hlist_del_init_rcu(&ifp->addr_lst)) and drops all references (__in6_ifa_put(ifp) + in6_ifa_put(ifp)). With bad enough timing, this can happen: 1. In ipv6_get_ifaddr, hlist_for_each_entry_rcu returns an entry. 2. • https://git.kernel.org/stable/c/5c578aedcb21d79eeb4e9cf04ca5b276ac82614c https://git.kernel.org/stable/c/b4b3b69a19016d4e7fbdbd1dbcc184915eb862e1 https://git.kernel.org/stable/c/cca606e14264098cba65efa82790825dbf69e903 https://git.kernel.org/stable/c/3fb02ec57ead2891a2306af8c51a306bc5945e70 https://git.kernel.org/stable/c/4b19e9507c275de0cfe61c24db69179dc52cf9fb https://git.kernel.org/stable/c/de76ae9ea1a6cf9e77fcec4f2df2904e26c23ceb https://git.kernel.org/stable/c/01b11a0566670612bd464a932e5ac2eae53d8652 https://git.kernel.org/stable/c/6cdb20c342cd0193d3e956e3d83981d0f • CWE-770: Allocation of Resources Without Limits or Throttling •

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix not validating setsockopt user input syzbot reported rfcomm_sock_setsockopt_old() is copying data without checking user input length. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old net/bluetooth/rfcomm/sock.c:632 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70 net/bluetooth/rfcomm/sock.c:673 Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: RFCOMM: solución al no validar la entrada del usuario de setsockopt. Syzbot informó que rfcomm_sock_setsockopt_old() está copiando datos sin verificar la longitud de la entrada del usuario. BUG: KASAN: slab fuera de los límites en copy_from_sockptr_offset include/linux/sockptr.h:49 [en línea] BUG: KASAN: slab fuera de los límites en copy_from_sockptr include/linux/sockptr.h:55 [en línea] ERROR: KASAN: losa fuera de los límites en rfcomm_sock_setsockopt_old net/bluetooth/rfcomm/sock.c:632 [en línea] BUG: KASAN: losa fuera de los límites en rfcomm_sock_setsockopt+0x893/0xa70 net/bluetooth/rfcomm/ sock.c:673 Lectura de tamaño 4 en addr ffff8880209a8bc3 por tarea syz-executor632/5064 • https://git.kernel.org/stable/c/9f2c8a03fbb3048cf38b158f87aa0c3c09bca084 https://git.kernel.org/stable/c/eea40d33bf936a5c7fb03c190e61e0cfee00e872 https://git.kernel.org/stable/c/4ea65e2095e9bd151d0469328dd7fc2858feb546 https://git.kernel.org/stable/c/c3f787a3eafe519c93df9abbb0ca5145861c8d0f https://git.kernel.org/stable/c/a97de7bff13b1cc825c1b1344eaed8d6c2d3e695 •

CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: drm/client: Fully protect modes[] with dev->mode_config.mutex The modes[] array contains pointers to modes on the connectors' mode lists, which are protected by dev->mode_config.mutex. Thus we need to extend modes[] the same protection or by the time we use it the elements may already be pointing to freed/reused memory. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/client: Protege completamente los modos[] con dev->mode_config.mutex. La matriz modes[] contiene punteros a los modos en las listas de modos de los conectores, que están protegidos por dev- >mode_config.mutex. Por lo tanto, necesitamos extender modes[] la misma protección o, cuando la usemos, es posible que los elementos ya estén apuntando a la memoria liberada/reutilizada. • https://git.kernel.org/stable/c/5a2f957e3c4553bbb100504a1acfeaeb33f4ca4e https://git.kernel.org/stable/c/41586487769eede64ab1aa6c65c74cbf76c12ef0 https://git.kernel.org/stable/c/d2dc6600d4e3e1453e3b1fb233e9f97e2a1ae949 https://git.kernel.org/stable/c/18c8cc6680ce938d0458859b6a08b4d34f7d8055 https://git.kernel.org/stable/c/04e018bd913d3d3336ab7d21c2ad31a9175fe984 https://git.kernel.org/stable/c/8ceb873d816786a7c8058f50d903574aff8d3764 https://git.kernel.org/stable/c/3eadd887dbac1df8f25f701e5d404d1b90fd0fea https://lists.debian.org/debian-lts-announce/2024/06/ •

CVSS: -EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: btrfs: make sure that WRITTEN is set on all metadata blocks We previously would call btrfs_check_leaf() if we had the check integrity code enabled, which meant that we could only run the extended leaf checks if we had WRITTEN set on the header flags. This leaves a gap in our checking, because we could end up with corruption on disk where WRITTEN isn't set on the leaf, and then the extended leaf checks don't get run which we rely on to validate all of the item pointers to make sure we don't access memory outside of the extent buffer. However, since 732fab95abe2 ("btrfs: check-integrity: remove CONFIG_BTRFS_FS_CHECK_INTEGRITY option") we no longer call btrfs_check_leaf() from btrfs_mark_buffer_dirty(), which means we only ever call it on blocks that are being written out, and thus have WRITTEN set, or that are being read in, which should have WRITTEN set. Add checks to make sure we have WRITTEN set appropriately, and then make sure __btrfs_check_leaf() always does the item checking. This will protect us from file systems that have been corrupted and no longer have WRITTEN set on some of the blocks. This was hit on a crafted image tweaking the WRITTEN bit and reported by KASAN as out-of-bound access in the eb accessors. The example is a dir item at the end of an eb. [2.042] BTRFS warning (device loop1): bad eb member start: ptr 0x3fff start 30572544 member offset 16410 size 2 [2.040] general protection fault, probably for non-canonical address 0xe0009d1000000003: 0000 [#1] PREEMPT SMP KASAN NOPTI [2.537] KASAN: maybe wild-memory-access in range [0x0005088000000018-0x000508800000001f] [2.729] CPU: 0 PID: 2587 Comm: mount Not tainted 6.8.2 #1 [2.729] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [2.621] RIP: 0010:btrfs_get_16+0x34b/0x6d0 [2.621] RSP: 0018:ffff88810871fab8 EFLAGS: 00000206 [2.621] RAX: 0000a11000000003 RBX: ffff888104ff8720 RCX: ffff88811b2288c0 [2.621] RDX: dffffc0000000000 RSI: ffffffff81dd8aca RDI: ffff88810871f748 [2.621] RBP: 000000000000401a R08: 0000000000000001 R09: ffffed10210e3ee9 [2.621] R10: ffff88810871f74f R11: 205d323430333737 R12: 000000000000001a [2.621] R13: 000508800000001a R14: 1ffff110210e3f5d R15: ffffffff850011e8 [2.621] FS: 00007f56ea275840(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000 [2.621] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [2.621] CR2: 00007febd13b75c0 CR3: 000000010bb50000 CR4: 00000000000006f0 [2.621] Call Trace: [2.621] <TASK> [2.621] ? show_regs+0x74/0x80 [2.621] ? die_addr+0x46/0xc0 [2.621] ? • https://git.kernel.org/stable/c/ef3ba8ce8cf7075b716aa4afcefc3034215878ee https://git.kernel.org/stable/c/e03418abde871314e1a3a550f4c8afb7b89cb273 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OTB4HWU2PTVW5NEYHHLOCXDKG3PYA534 •