CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2023-52805 – jfs: fix array-index-out-of-bounds in diAlloc
https://notcve.org/view.php?id=CVE-2023-52805
In the Linux kernel, the following vulnerability has been resolved: jfs: fix array-index-out-of-bounds in diAlloc Currently there is not check against the agno of the iag while allocating new inodes to avoid fragmentation problem. Added the check which is required. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: corrige el índice de matriz fuera de los límites en diAlloc. Actualmente no se verifica el agno del iag al asignar nuevos inodos para evitar problemas de fragmentación. Se agregó la comprobación que se requiere. • https://git.kernel.org/stable/c/2308d0fb0dc32446b4e6ca37cd09c30374bb64e9 https://git.kernel.org/stable/c/cf7e3e84df36a9953796c737f080712f631d7083 https://git.kernel.org/stable/c/7467ca10a5ff09b0e87edf6c4d2a4bfdee69cf2c https://git.kernel.org/stable/c/1ba7df5457dc1c1071c5f92ac11323533a6430e1 https://git.kernel.org/stable/c/64f062baf202b82f54987a3f614a6c8f3e466641 https://git.kernel.org/stable/c/8c68af2af697ba2ba3b138be0c6d72e2ce3a3d6d https://git.kernel.org/stable/c/665b44e55c2767a4f899c3b18f49e9e1c9983777 https://git.kernel.org/stable/c/1708d0a9917fea579cc9da3d87b154285 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2023-52804 – fs/jfs: Add validity check for db_maxag and db_agpref
https://notcve.org/view.php?id=CVE-2023-52804
In the Linux kernel, the following vulnerability has been resolved: fs/jfs: Add validity check for db_maxag and db_agpref Both db_maxag and db_agpref are used as the index of the db_agfree array, but there is currently no validity check for db_maxag and db_agpref, which can lead to errors. The following is related bug reported by Syzbot: UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:639:20 index 7936 is out of range for type 'atomic_t[128]' Add checking that the values of db_maxag and db_agpref are valid indexes for the db_agfree array. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: fs/jfs: agregue verificación de validez para db_maxag y db_agpref. Tanto db_maxag como db_agpref se utilizan como índice de la matriz db_agfree, pero actualmente no hay verificación de validez para db_maxag y db_agpref, lo cual puede dar lugar a errores. El siguiente es un error relacionado reportado por Syzbot: UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:639:20 el índice 7936 está fuera de rango para el tipo 'atomic_t[128]' Agregue verificando que el Los valores de db_maxag y db_agpref son índices válidos para la matriz db_agfree. • https://git.kernel.org/stable/c/a0649e2dd4a3595b5595a29d0064d047c2fae2fb https://git.kernel.org/stable/c/ce15b0f1a431168f07b1cc6c9f71206a2db5c809 https://git.kernel.org/stable/c/32bd8f1cbcf8b663e29dd1f908ba3a129541a11b https://git.kernel.org/stable/c/c6c8863fb3f57700ab583d875adda04caaf2278a https://git.kernel.org/stable/c/1f74d336990f37703a8eee77153463d65b67f70e https://git.kernel.org/stable/c/5013f8269887642cca784adc8db9b5f0b771533f https://git.kernel.org/stable/c/dca403bb035a565bb98ecc1dda5d30f676feda40 https://git.kernel.org/stable/c/2323de34a3ae61a9f9b544c18583f71ce •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52803 – SUNRPC: Fix RPC client cleaned up the freed pipefs dentries
https://notcve.org/view.php?id=CVE-2023-52803
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix RPC client cleaned up the freed pipefs dentries RPC client pipefs dentries cleanup is in separated rpc_remove_pipedir() workqueue,which takes care about pipefs superblock locking. In some special scenarios, when kernel frees the pipefs sb of the current client and immediately alloctes a new pipefs sb, rpc_remove_pipedir function would misjudge the existence of pipefs sb which is not the one it used to hold. As a result, the rpc_remove_pipedir would clean the released freed pipefs dentries. To fix this issue, rpc_remove_pipedir should check whether the current pipefs sb is consistent with the original pipefs sb. This error can be catched by KASAN: ========================================================= [ 250.497700] BUG: KASAN: slab-use-after-free in dget_parent+0x195/0x200 [ 250.498315] Read of size 4 at addr ffff88800a2ab804 by task kworker/0:18/106503 [ 250.500549] Workqueue: events rpc_free_client_work [ 250.501001] Call Trace: [ 250.502880] kasan_report+0xb6/0xf0 [ 250.503209] ? dget_parent+0x195/0x200 [ 250.503561] dget_parent+0x195/0x200 [ 250.503897] ? __pfx_rpc_clntdir_depopulate+0x10/0x10 [ 250.504384] rpc_rmdir_depopulate+0x1b/0x90 [ 250.504781] rpc_remove_client_dir+0xf5/0x150 [ 250.505195] rpc_free_client_work+0xe4/0x230 [ 250.505598] process_one_work+0x8ee/0x13b0 ... [ 22.039056] Allocated by task 244: [ 22.039390] kasan_save_stack+0x22/0x50 [ 22.039758] kasan_set_track+0x25/0x30 [ 22.040109] __kasan_slab_alloc+0x59/0x70 [ 22.040487] kmem_cache_alloc_lru+0xf0/0x240 [ 22.040889] __d_alloc+0x31/0x8e0 [ 22.041207] d_alloc+0x44/0x1f0 [ 22.041514] __rpc_lookup_create_exclusive+0x11c/0x140 [ 22.041987] rpc_mkdir_populate.constprop.0+0x5f/0x110 [ 22.042459] rpc_create_client_dir+0x34/0x150 [ 22.042874] rpc_setup_pipedir_sb+0x102/0x1c0 [ 22.043284] rpc_client_register+0x136/0x4e0 [ 22.043689] rpc_new_client+0x911/0x1020 [ 22.044057] rpc_create_xprt+0xcb/0x370 [ 22.044417] rpc_create+0x36b/0x6c0 ... [ 22.049524] Freed by task 0: [ 22.049803] kasan_save_stack+0x22/0x50 [ 22.050165] kasan_set_track+0x25/0x30 [ 22.050520] kasan_save_free_info+0x2b/0x50 [ 22.050921] __kasan_slab_free+0x10e/0x1a0 [ 22.051306] kmem_cache_free+0xa5/0x390 [ 22.051667] rcu_core+0x62c/0x1930 [ 22.051995] __do_softirq+0x165/0x52a [ 22.052347] [ 22.052503] Last potentially related work creation: [ 22.052952] kasan_save_stack+0x22/0x50 [ 22.053313] __kasan_record_aux_stack+0x8e/0xa0 [ 22.053739] __call_rcu_common.constprop.0+0x6b/0x8b0 [ 22.054209] dentry_free+0xb2/0x140 [ 22.054540] __dentry_kill+0x3be/0x540 [ 22.054900] shrink_dentry_list+0x199/0x510 [ 22.055293] shrink_dcache_parent+0x190/0x240 [ 22.055703] do_one_tree+0x11/0x40 [ 22.056028] shrink_dcache_for_umount+0x61/0x140 [ 22.056461] generic_shutdown_super+0x70/0x590 [ 22.056879] kill_anon_super+0x3a/0x60 [ 22.057234] rpc_kill_sb+0x121/0x200 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: SUNRPC: el cliente RPC limpió los pipefs dentries liberados. La limpieza de pipefs dentries del cliente RPC está en la cola de trabajo separada rpc_remove_pipedir(), que se encarga del bloqueo del superbloque de pipefs. • https://git.kernel.org/stable/c/0157d021d23a087eecfa830502f81cfe843f0d16 https://git.kernel.org/stable/c/17866066b8ac1cc38fb449670bc15dc9fee4b40a https://git.kernel.org/stable/c/7d61d1da2ed1f682c41cae0c8d4719cdaccee5c5 https://git.kernel.org/stable/c/dedf2a0eb9448ae73b270743e6ea9b108189df46 https://git.kernel.org/stable/c/194454afa6aa9d6ed74f0c57127bc8beb27c20df https://git.kernel.org/stable/c/7749fd2dbef72a52b5c9ffdbf877691950ed4680 https://git.kernel.org/stable/c/1cdb52ffd6600a37bd355d8dce58ecd03e55e618 https://git.kernel.org/stable/c/cc2e7ebbeb1d0601f7f3c8d93b78fcc03 • CWE-416: Use After Free •
CVSS: 4.4EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52800 – wifi: ath11k: fix htt pktlog locking
https://notcve.org/view.php?id=CVE-2023-52800
In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix htt pktlog locking The ath11k active pdevs are protected by RCU but the htt pktlog handling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a read-side critical section. Mark the code in question as an RCU read-side critical section to avoid any potential use-after-free issues. Compile tested only. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: ath11k: corrige el bloqueo de htt pktlog. Los pdevs activos de ath11k están protegidos por RCU, pero el código de manejo de htt pktlog que llama a ath11k_mac_get_ar_by_pdev_id() no se marcó como una sección crítica del lado de lectura. Marque el código en cuestión como una sección crítica del lado de lectura de RCU para evitar posibles problemas de use after free. Compilación probada únicamente. • https://git.kernel.org/stable/c/d5c65159f2895379e11ca13f62feabe93278985d https://git.kernel.org/stable/c/03ed26935bebf6b6fd8a656490bf3dcc71b72679 https://git.kernel.org/stable/c/3a51e6b4da71fdfa43ec006d6abc020f3e22d14e https://git.kernel.org/stable/c/e3199b3fac65c9f103055390b6fd07c5cffa5961 https://git.kernel.org/stable/c/423762f021825b5e57c3d6f01ff96a9ff19cdcd8 https://git.kernel.org/stable/c/69cede2a5a5f60e3f5602b901b52cb64edd2ea6c https://git.kernel.org/stable/c/3f77c7d605b29df277d77e9ee75d96e7ad145d2d https://access.redhat.com/security/cve/CVE-2023-52800 • CWE-413: Improper Resource Locking •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2023-52799 – jfs: fix array-index-out-of-bounds in dbFindLeaf
https://notcve.org/view.php?id=CVE-2023-52799
In the Linux kernel, the following vulnerability has been resolved: jfs: fix array-index-out-of-bounds in dbFindLeaf Currently while searching for dmtree_t for sufficient free blocks there is an array out of bounds while getting element in tp->dm_stree. To add the required check for out of bound we first need to determine the type of dmtree. Thus added an extra parameter to dbFindLeaf so that the type of tree can be determined and the required check can be applied. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: jfs: corrige el índice de matriz fuera de los límites en dbFindLeaf. Actualmente, mientras se busca dmtree_t para suficientes bloques libres, hay una matriz fuera de los límites al obtener el elemento en tp->dm_stree . • https://git.kernel.org/stable/c/20f9310a18e3e99fc031e036fcbed67105ae1859 https://git.kernel.org/stable/c/86df90f3fea7c5591f05c8a0010871d435e83046 https://git.kernel.org/stable/c/ecfb47f13b08b02cf28b7b50d4941eefa21954d2 https://git.kernel.org/stable/c/81aa58cd8495b8c3b527f58ccbe19478d8087f61 https://git.kernel.org/stable/c/da3da5e1e6f71c21d8e6149d7076d936ef5d4cb9 https://git.kernel.org/stable/c/a50b796d36719757526ee094c703378895ab5e67 https://git.kernel.org/stable/c/88b7894a8f8705bf4e7ea90b10229376abf14514 https://git.kernel.org/stable/c/87c681ab49e99039ff2dd3e7185241738 •