Page 285 of 2647 results (0.012 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/memhp: Fix access beyond end of drmem array dlpar_memory_remove_by_index() may access beyond the bounds of the drmem lmb array when the LMB lookup fails to match an entry with the given DRC index. When the search fails, the cursor is left pointing to &drmem_info->lmbs[drmem_info->n_lmbs], which is one element past the last valid entry in the array. The debug message at the end of the function then dereferences this pointer: pr_debug("Failed to hot-remove memory at %llx\n", lmb->base_addr); This was found by inspection and confirmed with KASAN: pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234 ================================================================== BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658 Read of size 8 at addr c000000364e97fd0 by task bash/949 dump_stack_lvl+0xa4/0xfc (unreliable) print_report+0x214/0x63c kasan_report+0x140/0x2e0 __asan_load8+0xa8/0xe0 dlpar_memory+0x298/0x1658 handle_dlpar_errorlog+0x130/0x1d0 dlpar_store+0x18c/0x3e0 kobj_attr_store+0x68/0xa0 sysfs_kf_write+0xc4/0x110 kernfs_fop_write_iter+0x26c/0x390 vfs_write+0x2d4/0x4e0 ksys_write+0xac/0x1a0 system_call_exception+0x268/0x530 system_call_vectored_common+0x15c/0x2ec Allocated by task 1: kasan_save_stack+0x48/0x80 kasan_set_track+0x34/0x50 kasan_save_alloc_info+0x34/0x50 __kasan_kmalloc+0xd0/0x120 __kmalloc+0x8c/0x320 kmalloc_array.constprop.0+0x48/0x5c drmem_init+0x2a0/0x41c do_one_initcall+0xe0/0x5c0 kernel_init_freeable+0x4ec/0x5a0 kernel_init+0x30/0x1e0 ret_from_kernel_user_thread+0x14/0x1c The buggy address belongs to the object at c000000364e80000 which belongs to the cache kmalloc-128k of size 131072 The buggy address is located 0 bytes to the right of allocated 98256-byte region [c000000364e80000, c000000364e97fd0) ================================================================== pseries-hotplug-mem: Failed to hot-remove memory at 0 Log failed lookups with a separate message and dereference the cursor only when it points to a valid entry. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/pseries/memhp: corrige el acceso más allá del final de la matriz drmem dlpar_memory_remove_by_index() puede acceder más allá de los límites de la matriz lmb drmem cuando la búsqueda de LMB no coincide con una entrada con el valor dado Índice de la República Democrática del Congo. Cuando la búsqueda falla, el cursor queda apuntando a &drmem_info->lmbs[drmem_info->n_lmbs], que es un elemento después de la última entrada válida en la matriz. • https://git.kernel.org/stable/c/51925fb3c5c901aa06cdc853268a6e19e19bcdc7 https://git.kernel.org/stable/c/bb79613a9a704469ddb8d6c6029d532a5cea384c https://git.kernel.org/stable/c/9b5f03500bc5b083c0df696d7dd169d7ef3dd0c7 https://git.kernel.org/stable/c/b582aa1f66411d4adcc1aa55b8c575683fb4687e https://git.kernel.org/stable/c/999a27b3ce9a69d54ccd5db000ec3a447bc43e6d https://git.kernel.org/stable/c/026fd977dc50ff4a5e09bfb0603557f104d3f3a0 https://git.kernel.org/stable/c/df16afba2378d985359812c865a15c05c70a967e https://git.kernel.org/stable/c/708a4b59baad96c4718dc0bd3a3427d3a • CWE-125: Out-of-bounds Read CWE-129: Improper Validation of Array Index •

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

In the Linux kernel, the following vulnerability has been resolved: mtd: Fix gluebi NULL pointer dereference caused by ftl notifier If both ftl.ko and gluebi.ko are loaded, the notifier of ftl triggers NULL pointer dereference when trying to access ‘gluebi->desc’ in gluebi_read(). ubi_gluebi_init ubi_register_volume_notifier ubi_enumerate_volumes ubi_notify_all gluebi_notify nb->notifier_call() gluebi_create mtd_device_register mtd_device_parse_register add_mtd_device blktrans_notify_add not->add() ftl_add_mtd tr->add_mtd() scan_header mtd_read mtd_read_oob mtd_read_oob_std gluebi_read mtd->read() gluebi->desc - NULL Detailed reproduction information available at the Link [1], In the normal case, obtain gluebi->desc in the gluebi_get_device(), and access gluebi->desc in the gluebi_read(). However, gluebi_get_device() is not executed in advance in the ftl_add_mtd() process, which leads to NULL pointer dereference. The solution for the gluebi module is to run jffs2 on the UBI volume without considering working with ftl or mtdblock [2]. Therefore, this problem can be avoided by preventing gluebi from creating the mtdblock device after creating mtd partition of the type MTD_UBIVOLUME. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mtd: corrige la desreferencia del puntero NULL de Gluebi causada por el notificador ftl. Si se cargan tanto ftl.ko como pegamentobi.ko, el notificador de ftl activa la desreferencia del puntero NULL al intentar acceder a 'gluebi-. >desc' en pegamentobi_read(). ubi_gluebi_init ubi_register_volume_notifier ubi_enumerate_volumes ubi_notify_all pegamentobi_notify nb->notifier_call() pegamentobi_create mtd_device_register mtd_device_parse_register add_mtd_device blktrans_notify_add not->add() ftl_add_mtd tr->add_mtd() scan_header mtd_read mtd_read_oob mtd_read_oob_std pegamentobi_read mtd->read() pegamentobi->desc - NULL Información detallada de reproducción disponible en el enlace [1], en el caso normal, obtenga pegamentobi->desc en pegamentobi_get_device() y acceda a pegamentobi->desc en pegamentobi_read(). • https://git.kernel.org/stable/c/2ba3d76a1e29f2ba64fbc762875cf9fb2d4ba2ba https://git.kernel.org/stable/c/aeba358bcc8ffddf9b4a9bd0e5ec9eb338d46022 https://git.kernel.org/stable/c/1bf4fe14e97cda621522eb2f28b0a4e87c5b0745 https://git.kernel.org/stable/c/001a3f59d8c914ef8273461d4bf495df384cc5f8 https://git.kernel.org/stable/c/d8ac2537763b54d278b80b2b080e1652523c7d4c https://git.kernel.org/stable/c/5389407bba1eab1266c6d83e226fb0840cb98dd5 https://git.kernel.org/stable/c/cfd7c9d260dc0a3baaea05a122a19ab91e193c65 https://git.kernel.org/stable/c/b36aaa64d58aaa2f2cbc8275e89bae76a • CWE-476: NULL Pointer Dereference •

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

In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix use after free on context disconnection Upon module load, a kthread is created targeting the pvr2_context_thread_func function, which may call pvr2_context_destroy and thus call kfree() on the context object. However, that might happen before the usb hub_event handler is able to notify the driver. This patch adds a sanity check before the invalid read reported by syzbot, within the context disconnection call stack. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: pvrusb2: corrige el use after free de desconexión de contexto. Al cargar el módulo, se crea un kthread dirigido a la función pvr2_context_thread_func, que puede llamar a pvr2_context_destroy y, por lo tanto, llamar a kfree() en el objeto de contexto. • https://git.kernel.org/stable/c/e5be15c63804e05b5a94197524023702a259e308 https://git.kernel.org/stable/c/ec36c134dd020d28e312c2f1766f85525e747aab https://git.kernel.org/stable/c/47aa8fcd5e8b5563af4042a00f25ba89bef8f33d https://git.kernel.org/stable/c/3233d8bf7893550045682192cb227af7fa3defeb https://git.kernel.org/stable/c/ec3634ebe23fc3c44ebc67c6d25917300bc68c08 https://git.kernel.org/stable/c/30773ea47d41773f9611ffb4ebc9bda9d19a9e7e https://git.kernel.org/stable/c/2cf0005d315549b8d2b940ff96a66c2a889aa795 https://git.kernel.org/stable/c/437b5f57732bb4cc32cc9f8895d2010ee • CWE-416: Use After Free •

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

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid dirent corruption As Al reported in link[1]: f2fs_rename() ... if (old_dir != new_dir && !whiteout) f2fs_set_link(old_inode, old_dir_entry, old_dir_page, new_dir); else f2fs_put_page(old_dir_page, 0); You want correct inumber in the ".." link. And cross-directory rename does move the source to new parent, even if you'd been asked to leave a whiteout in the old place. [1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/ With below testcase, it may cause dirent corruption, due to it missed to call f2fs_set_link() to update ".." link to new directory. - mkdir -p dir/foo - renameat2 -w dir/foo bar [ASSERT] (__chk_dots_dentries:1421) --> Bad inode number[0x4] for '. • https://git.kernel.org/stable/c/7e01e7ad746bc8198a8b46163ddc73a1c7d22339 https://git.kernel.org/stable/c/02160112e6d45c2610b049df6eb693d7a2e57b46 https://git.kernel.org/stable/c/5624a3c1b1ebc8991318e1cce2aa719542991024 https://git.kernel.org/stable/c/6f866885e147d33efc497f1095f35b2ee5ec7310 https://git.kernel.org/stable/c/f100ba617d8be6c98a68f3744ef7617082975b77 https://git.kernel.org/stable/c/f0145860c20be6bae6785c7a2249577674702ac7 https://git.kernel.org/stable/c/d3c0b49aaa12a61d560528f5d605029ab57f0728 https://git.kernel.org/stable/c/2fb4867f4405aea8c0519d7d188207f23 • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer •

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

In the Linux kernel, the following vulnerability has been resolved: apparmor: avoid crash when parsed profile name is empty When processing a packed profile in unpack_profile() described like "profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...}" a string ":samba-dcerpcd" is unpacked as a fully-qualified name and then passed to aa_splitn_fqname(). aa_splitn_fqname() treats ":samba-dcerpcd" as only containing a namespace. Thus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Later aa_alloc_profile() crashes as the new profile name is NULL now. general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 6 PID: 1657 Comm: apparmor_parser Not tainted 6.7.0-rc2-dirty #16 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 RIP: 0010:strlen+0x1e/0xa0 Call Trace: <TASK> ? strlen+0x1e/0xa0 aa_policy_init+0x1bb/0x230 aa_alloc_profile+0xb1/0x480 unpack_profile+0x3bc/0x4960 aa_unpack+0x309/0x15e0 aa_replace_profiles+0x213/0x33c0 policy_update+0x261/0x370 profile_replace+0x20e/0x2a0 vfs_write+0x2af/0xe00 ksys_write+0x126/0x250 do_syscall_64+0x46/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 </TASK> ---[ end trace 0000000000000000 ]--- RIP: 0010:strlen+0x1e/0xa0 It seems such behaviour of aa_splitn_fqname() is expected and checked in other places where it is called (e.g. aa_remove_profiles). Well, there is an explicit comment "a ns name without a following profile is allowed" inside. AFAICS, nothing can prevent unpacked "name" to be in form like ":samba-dcerpcd" - it is passed from userspace. Deny the whole profile set replacement in such case and inform user with EPROTO and an explaining message. Found by Linux Verification Center (linuxtesting.org). • https://git.kernel.org/stable/c/04dc715e24d0820bf8740e1a1135ed61fe162bc8 https://git.kernel.org/stable/c/9286ee97aa4803d99185768735011d0d65827c9e https://git.kernel.org/stable/c/1d8e62b5569cc1466ceb8a7e4872cf10160a9dcf https://git.kernel.org/stable/c/5ff00408e5029d3550ee77f62dc15f1e15c47f87 https://git.kernel.org/stable/c/0a12db736edbb4933e4274932aeea594b5876fa4 https://git.kernel.org/stable/c/9d4fa5fe2b1d56662afd14915a73b4d0783ffa45 https://git.kernel.org/stable/c/5c0392fdafb0a2321311900be83ffa572bef8203 https://git.kernel.org/stable/c/77ab09b92f16c8439a948d1af48919695 • CWE-476: NULL Pointer Dereference •