CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52499 – powerpc/47x: Fix 47x syscall return crash
https://notcve.org/view.php?id=CVE-2023-52499
In the Linux kernel, the following vulnerability has been resolved: powerpc/47x: Fix 47x syscall return crash Eddie reported that newer kernels were crashing during boot on his 476 FSP2 system: kernel tried to execute user page (b7ee2000) - exploit attempt? (uid: 0) BUG: Unable to handle kernel instruction fetch Faulting instruction address: 0xb7ee2000 Oops: Kernel access of bad area, sig: 11 [#1] BE PAGE_SIZE=4K FSP-2 Modules linked in: CPU: 0 PID: 61 Comm: mount Not tainted 6.1.55-d23900f.ppcnf-fsp2 #1 Hardware name: ibm,fsp2 476fpe 0x7ff520c0 FSP-2 NIP: b7ee2000 LR: 8c008000 CTR: 00000000 REGS: bffebd83 TRAP: 0400 Not tainted (6.1.55-d23900f.ppcnf-fs p2) MSR: 00000030 <IR,DR> CR: 00001000 XER: 20000000 GPR00: c00110ac bffebe63 bffebe7e bffebe88 8c008000 00001000 00000d12 b7ee2000 GPR08: 00000033 00000000 00000000 c139df10 48224824 1016c314 10160000 00000000 GPR16: 10160000 10160000 00000008 00000000 10160000 00000000 10160000 1017f5b0 GPR24: 1017fa50 1017f4f0 1017fa50 1017f740 1017f630 00000000 00000000 1017f4f0 NIP [b7ee2000] 0xb7ee2000 LR [8c008000] 0x8c008000 Call Trace: Instruction dump: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX ---[ end trace 0000000000000000 ]--- The problem is in ret_from_syscall where the check for icache_44x_need_flush is done. When the flush is needed the code jumps out-of-line to do the flush, and then intends to jump back to continue the syscall return. However the branch back to label 1b doesn't return to the correct location, instead branching back just prior to the return to userspace, causing bogus register values to be used by the rfi. The breakage was introduced by commit 6f76a01173cc ("powerpc/syscall: implement system call entry/exit logic in C for PPC32") which inadvertently removed the "1" label and reused it elsewhere. Fix it by adding named local labels in the correct locations. Note that the return label needs to be outside the ifdef so that CONFIG_PPC_47x=n compiles. • https://git.kernel.org/stable/c/6f76a01173ccaa363739f913394d4e138d92d718 https://git.kernel.org/stable/c/29017ab1a539101d9c7bec63cc13a019f97b2820 https://git.kernel.org/stable/c/8ac2689502f986a46f4221e239d4ff2897f1ccb3 https://git.kernel.org/stable/c/70f6756ad96dd70177dddcfac2fe4bd4bb320746 https://git.kernel.org/stable/c/f0eee815babed70a749d2496a7678be5b45b4c14 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48628 – ceph: drop messages from MDS when unmounting
https://notcve.org/view.php?id=CVE-2022-48628
In the Linux kernel, the following vulnerability has been resolved: ceph: drop messages from MDS when unmounting When unmounting all the dirty buffers will be flushed and after the last osd request is finished the last reference of the i_count will be released. Then it will flush the dirty cap/snap to MDSs, and the unmounting won't wait the possible acks, which will ihold the inodes when updating the metadata locally but makes no sense any more, of this. This will make the evict_inodes() to skip these inodes. If encrypt is enabled the kernel generate a warning when removing the encrypt keys when the skipped inodes still hold the keyring: WARNING: CPU: 4 PID: 168846 at fs/crypto/keyring.c:242 fscrypt_destroy_keyring+0x7e/0xd0 CPU: 4 PID: 168846 Comm: umount Tainted: G S 6.1.0-rc5-ceph-g72ead199864c #1 Hardware name: Supermicro SYS-5018R-WR/X10SRW-F, BIOS 2.0 12/17/2015 RIP: 0010:fscrypt_destroy_keyring+0x7e/0xd0 RSP: 0018:ffffc9000b277e28 EFLAGS: 00010202 RAX: 0000000000000002 RBX: ffff88810d52ac00 RCX: ffff88810b56aa00 RDX: 0000000080000000 RSI: ffffffff822f3a09 RDI: ffff888108f59000 RBP: ffff8881d394fb88 R08: 0000000000000028 R09: 0000000000000000 R10: 0000000000000001 R11: 11ff4fe6834fcd91 R12: ffff8881d394fc40 R13: ffff888108f59000 R14: ffff8881d394f800 R15: 0000000000000000 FS: 00007fd83f6f1080(0000) GS:ffff88885fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f918d417000 CR3: 000000017f89a005 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> generic_shutdown_super+0x47/0x120 kill_anon_super+0x14/0x30 ceph_kill_sb+0x36/0x90 [ceph] deactivate_locked_super+0x29/0x60 cleanup_mnt+0xb8/0x140 task_work_run+0x67/0xb0 exit_to_user_mode_prepare+0x23d/0x240 syscall_exit_to_user_mode+0x25/0x60 do_syscall_64+0x40/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fd83dc39e9b Later the kernel will crash when iput() the inodes and dereferencing the "sb->s_master_keys", which has been released by the generic_shutdown_super(). • https://git.kernel.org/stable/c/89744b64914426cbabceb3d8a149176b5dafdfb5 https://git.kernel.org/stable/c/47f82395f04a976d4fa97de7f2acffa1c1096571 https://git.kernel.org/stable/c/e3dfcab2080dc1f9a4b09cc1327361bc2845bfcd •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26621 – mm: huge_memory: don't force huge page alignment on 32 bit
https://notcve.org/view.php?id=CVE-2024-26621
In the Linux kernel, the following vulnerability has been resolved: mm: huge_memory: don't force huge page alignment on 32 bit commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries") caused two issues [1] [2] reported on 32 bit system or compat userspace. It doesn't make too much sense to force huge page alignment on 32 bit system due to the constrained virtual address space. [1] https://lore.kernel.org/linux-mm/d0a136a0-4a31-46bc-adf4-2db109a61672@kernel.org/ [2] https://lore.kernel.org/linux-mm/CAJuCfpHXLdQy1a2B6xN2d7quTYwg2OoZseYPZTRpU0eHHKD-sQ@mail.gmail.com/ En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm: huge_memory: no forzar una alineación de página enorme en el commit de 32 bits efa7df3e3bb5 ("mm: alinear asignaciones anónimas más grandes en los límites de THP") causó dos problemas [1] [2] informado en un sistema de 32 bits o espacio de usuario compatible. No tiene mucho sentido forzar una gran alineación de páginas en un sistema de 32 bits debido al espacio limitado de direcciones virtuales. [1] https://lore.kernel.org/linux-mm/d0a136a0-4a31-46bc-adf4-2db109a61672@kernel.org/ [2] https://lore.kernel.org/linux-mm/CAJuCfpHXLdQy1a2B6xN2d7quTYwg2OoZseYPZTRpU0eHHKD- sQ@mail.gmail.com/ • https://git.kernel.org/stable/c/1854bc6e2420472676c5c90d3d6b15f6cd640e40 https://git.kernel.org/stable/c/87632bc9ecff5ded93433bc0fca428019bdd1cfe https://git.kernel.org/stable/c/6ea9aa8d97e6563676094cb35755884173269555 https://git.kernel.org/stable/c/7432376c913381c5f24d373a87ff629bbde94b47 https://git.kernel.org/stable/c/4ef9ad19e17676b9ef071309bc62020e2373705d http://www.openwall.com/lists/oss-security/2024/07/08/3 http://www.openwall.com/lists/oss-security/2024/07/08/4 http://www.openwall.com/lists/oss-security/2024/07&# •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2022-48627 – vt: fix memory overlapping when deleting chars in the buffer
https://notcve.org/view.php?id=CVE-2022-48627
In the Linux kernel, the following vulnerability has been resolved: vt: fix memory overlapping when deleting chars in the buffer A memory overlapping copy occurs when deleting a long line. This memory overlapping copy can cause data corruption when scr_memcpyw is optimized to memcpy because memcpy does not ensure its behavior if the destination buffer overlaps with the source buffer. The line buffer is not always broken, because the memcpy utilizes the hardware acceleration, whose result is not deterministic. Fix this problem by using replacing the scr_memcpyw with scr_memmovew. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vt: corrige la superposición de memoria al eliminar caracteres en el búfer. Se produce una copia de memoria superpuesta al eliminar una línea larga. • https://git.kernel.org/stable/c/81732c3b2fede049a692e58a7ceabb6d18ffb18c https://git.kernel.org/stable/c/c8686c014b5e872ba7e334f33ca553f14446fc29 https://git.kernel.org/stable/c/815be99d934e3292906536275f2b8d5131cdf52c https://git.kernel.org/stable/c/bfee93c9a6c395f9aa62268f1cedf64999844926 https://git.kernel.org/stable/c/57964a5710252bc82fe22d9fa98c180c58c20244 https://git.kernel.org/stable/c/14d2cc21ca622310babf373e3a8f0b40acfe8265 https://git.kernel.org/stable/c/39cdb68c64d84e71a4a717000b6e5de208ee60cc https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-1260: Improper Handling of Overlap Between Protected Memory Ranges •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47081 – habanalabs/gaudi: Fix a potential use after free in gaudi_memset_device_memory
https://notcve.org/view.php?id=CVE-2021-47081
In the Linux kernel, the following vulnerability has been resolved: habanalabs/gaudi: Fix a potential use after free in gaudi_memset_device_memory Our code analyzer reported a uaf. In gaudi_memset_device_memory, cb is get via hl_cb_kernel_create() with 2 refcount. If hl_cs_allocate_job() failed, the execution runs into release_cb branch. One ref of cb is dropped by hl_cb_put(cb) and could be freed if other thread also drops one ref. Then cb is used by cb->id later, which is a potential uaf. My patch add a variable 'id' to accept the value of cb->id before the hl_cb_put(cb) is called, to avoid the potential uaf. • https://git.kernel.org/stable/c/423815bf02e257091d5337be5c63b57fc29e4254 https://git.kernel.org/stable/c/b49f5af30b0e4064fbd91e83823a4bfcb2c7a3e7 https://git.kernel.org/stable/c/115726c5d312b462c9d9931ea42becdfa838a076 •