Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions()<br /> <br /> When CONFIG_DAMON_VADDR_KUNIT_TEST=y and making CONFIG_DEBUG_KMEMLEAK=y<br /> and CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y, the below memory leak is detected.<br /> <br /> Since commit 9f86d624292c ("mm/damon/vaddr-test: remove unnecessary<br /> variables"), the damon_destroy_ctx() is removed, but still call<br /> damon_new_target() and damon_new_region(), the damon_region which is<br /> allocated by kmem_cache_alloc() in damon_new_region() and the damon_target<br /> which is allocated by kmalloc in damon_new_target() are not freed. And<br /> the damon_region which is allocated in damon_new_region() in<br /> damon_set_regions() is also not freed.<br /> <br /> So use damon_destroy_target to free all the damon_regions and damon_target.<br /> <br /> unreferenced object 0xffff888107c9a940 (size 64):<br /> comm "kunit_try_catch", pid 1069, jiffies 4294670592 (age 732.761s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b ............kkkk<br /> 60 c7 9c 07 81 88 ff ff f8 cb 9c 07 81 88 ff ff `...............<br /> backtrace:<br /> [] kmalloc_trace+0x27/0xa0<br /> [] damon_new_target+0x3f/0x1b0<br /> [] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0<br /> [] damon_test_apply_three_regions1+0x21e/0x260<br /> [] kunit_generic_run_threadfn_adapter+0x4a/0x90<br /> [] kthread+0x2b6/0x380<br /> [] ret_from_fork+0x2d/0x70<br /> [] ret_from_fork_asm+0x11/0x20<br /> unreferenced object 0xffff8881079cc740 (size 56):<br /> comm "kunit_try_catch", pid 1069, jiffies 4294670592 (age 732.761s)<br /> hex dump (first 32 bytes):<br /> 05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ................<br /> 6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk<br /> backtrace:<br /> [] damon_new_region+0x22/0x1c0<br /> [] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0<br /> [] damon_test_apply_three_regions1+0x21e/0x260<br /> [] kunit_generic_run_threadfn_adapter+0x4a/0x90<br /> [] kthread+0x2b6/0x380<br /> [] ret_from_fork+0x2d/0x70<br /> [] ret_from_fork_asm+0x11/0x20<br /> unreferenced object 0xffff888107c9ac40 (size 64):<br /> comm "kunit_try_catch", pid 1071, jiffies 4294670595 (age 732.843s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b ............kkkk<br /> a0 cc 9c 07 81 88 ff ff 78 a1 76 07 81 88 ff ff ........x.v.....<br /> backtrace:<br /> [] kmalloc_trace+0x27/0xa0<br /> [] damon_new_target+0x3f/0x1b0<br /> [] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0<br /> [] damon_test_apply_three_regions2+0x21e/0x260<br /> [] kunit_generic_run_threadfn_adapter+0x4a/0x90<br /> [] kthread+0x2b6/0x380<br /> [] ret_from_fork+0x2d/0x70<br /> [] ret_from_fork_asm+0x11/0x20<br /> unreferenced object 0xffff8881079ccc80 (size 56):<br /> comm "kunit_try_catch", pid 1071, jiffies 4294670595 (age 732.843s)<br /> hex dump (first 32 bytes):<br /> 05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ................<br /> 6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk<br /> backtrace:<br /> [] damon_new_region+0x22/0x1c0<br /> [] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0<br /> [] damon_test_apply_three_regions2+0x21e/0x260<br /> [] kunit_generic_run_threadfn_adapter+0x4a/0x90<br /> [] kthread+0x2b6/0x380<br /> [] ret_from_fork+0x2d/0x70<br /> [

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: dts: qcom: sdm845-db845c: Mark cont splash memory region as reserved<br /> <br /> Adding a reserved memory region for the framebuffer memory<br /> (the splash memory region set up by the bootloader).<br /> <br /> It fixes a kernel panic (arm-smmu: Unhandled context fault<br /> at this particular memory region) reported on DB845c running<br /> v5.10.y.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/slab_common: fix slab_caches list corruption after kmem_cache_destroy()<br /> <br /> After the commit in Fixes:, if a module that created a slab cache does not<br /> release all of its allocated objects before destroying the cache (at rmmod<br /> time), we might end up releasing the kmem_cache object without removing it<br /> from the slab_caches list thus corrupting the list as kmem_cache_destroy()<br /> ignores the return value from shutdown_cache(), which in turn never removes<br /> the kmem_cache object from slabs_list in case __kmem_cache_shutdown() fails<br /> to release all of the cache&amp;#39;s slabs.<br /> <br /> This is easily observable on a kernel built with CONFIG_DEBUG_LIST=y<br /> as after that ill release the system will immediately trip on list_add,<br /> or list_del, assertions similar to the one shown below as soon as another<br /> kmem_cache gets created, or destroyed:<br /> <br /> [ 1041.213632] list_del corruption. next-&gt;prev should be ffff89f596fb5768, but was 52f1e5016aeee75d. (next=ffff89f595a1b268)<br /> [ 1041.219165] ------------[ cut here ]------------<br /> [ 1041.221517] kernel BUG at lib/list_debug.c:62!<br /> [ 1041.223452] invalid opcode: 0000 [#1] PREEMPT SMP PTI<br /> [ 1041.225408] CPU: 2 PID: 1852 Comm: rmmod Kdump: loaded Tainted: G B W OE 6.5.0 #15<br /> [ 1041.228244] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc37 05/24/2023<br /> [ 1041.231212] RIP: 0010:__list_del_entry_valid+0xae/0xb0<br /> <br /> Another quick way to trigger this issue, in a kernel with CONFIG_SLUB=y,<br /> is to set slub_debug to poison the released objects and then just run<br /> cat /proc/slabinfo after removing the module that leaks slab objects,<br /> in which case the kernel will panic:<br /> <br /> [ 50.954843] general protection fault, probably for non-canonical address 0xa56b6b6b6b6b6b8b: 0000 [#1] PREEMPT SMP PTI<br /> [ 50.961545] CPU: 2 PID: 1495 Comm: cat Kdump: loaded Tainted: G B W OE 6.5.0 #15<br /> [ 50.966808] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc37 05/24/2023<br /> [ 50.972663] RIP: 0010:get_slabinfo+0x42/0xf0<br /> <br /> This patch fixes this issue by properly checking shutdown_cache()&amp;#39;s<br /> return value before taking the kmem_cache_release() branch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/meson: fix memory leak on -&gt;hpd_notify callback<br /> <br /> The EDID returned by drm_bridge_get_edid() needs to be freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "tty: n_gsm: fix UAF in gsm_cleanup_mux"<br /> <br /> This reverts commit 9b9c8195f3f0d74a826077fc1c01b9ee74907239.<br /> <br /> The commit above is reverted as it did not solve the original issue.<br /> <br /> gsm_cleanup_mux() tries to free up the virtual ttys by calling<br /> gsm_dlci_release() for each available DLCI. There, dlci_put() is called to<br /> decrease the reference counter for the DLCI via tty_port_put() which<br /> finally calls gsm_dlci_free(). This already clears the pointer which is<br /> being checked in gsm_cleanup_mux() before calling gsm_dlci_release().<br /> Therefore, it is not necessary to clear this pointer in gsm_cleanup_mux()<br /> as done in the reverted commit. The commit introduces a null pointer<br /> dereference:<br /> <br /> ? __die+0x1f/0x70<br /> ? page_fault_oops+0x156/0x420<br /> ? search_exception_tables+0x37/0x50<br /> ? fixup_exception+0x21/0x310<br /> ? exc_page_fault+0x69/0x150<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? tty_port_put+0x19/0xa0<br /> gsmtty_cleanup+0x29/0x80 [n_gsm]<br /> release_one_tty+0x37/0xe0<br /> process_one_work+0x1e6/0x3e0<br /> worker_thread+0x4c/0x3d0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0xe1/0x110<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x2f/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> <br /> The actual issue is that nothing guards dlci_put() from being called<br /> multiple times while the tty driver was triggered but did not yet finished<br /> calling gsm_dlci_free().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: uvcvideo: Fix OOB read<br /> <br /> If the index provided by the user is bigger than the mask size, we might do<br /> an out of bound read.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: fix potential key use-after-free<br /> <br /> When ieee80211_key_link() is called by ieee80211_gtk_rekey_add()<br /> but returns 0 due to KRACK protection (identical key reinstall),<br /> ieee80211_gtk_rekey_add() will still return a pointer into the<br /> key, in a potential use-after-free. This normally doesn&amp;#39;t happen<br /> since it&amp;#39;s only called by iwlwifi in case of WoWLAN rekey offload<br /> which has its own KRACK protection, but still better to fix, do<br /> that by returning an error code and converting that to success on<br /> the cfg80211 boundary only, leaving the error for bad callers of<br /> ieee80211_gtk_rekey_add().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: drop messages from MDS when unmounting<br /> <br /> When unmounting all the dirty buffers will be flushed and after<br /> the last osd request is finished the last reference of the i_count<br /> will be released. Then it will flush the dirty cap/snap to MDSs,<br /> and the unmounting won&amp;#39;t wait the possible acks, which will ihold<br /> the inodes when updating the metadata locally but makes no sense<br /> any more, of this. This will make the evict_inodes() to skip these<br /> inodes.<br /> <br /> If encrypt is enabled the kernel generate a warning when removing<br /> the encrypt keys when the skipped inodes still hold the keyring:<br /> <br /> WARNING: CPU: 4 PID: 168846 at fs/crypto/keyring.c:242 fscrypt_destroy_keyring+0x7e/0xd0<br /> CPU: 4 PID: 168846 Comm: umount Tainted: G S 6.1.0-rc5-ceph-g72ead199864c #1<br /> Hardware name: Supermicro SYS-5018R-WR/X10SRW-F, BIOS 2.0 12/17/2015<br /> RIP: 0010:fscrypt_destroy_keyring+0x7e/0xd0<br /> RSP: 0018:ffffc9000b277e28 EFLAGS: 00010202<br /> RAX: 0000000000000002 RBX: ffff88810d52ac00 RCX: ffff88810b56aa00<br /> RDX: 0000000080000000 RSI: ffffffff822f3a09 RDI: ffff888108f59000<br /> RBP: ffff8881d394fb88 R08: 0000000000000028 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 11ff4fe6834fcd91 R12: ffff8881d394fc40<br /> R13: ffff888108f59000 R14: ffff8881d394f800 R15: 0000000000000000<br /> FS: 00007fd83f6f1080(0000) GS:ffff88885fd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f918d417000 CR3: 000000017f89a005 CR4: 00000000003706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> generic_shutdown_super+0x47/0x120<br /> kill_anon_super+0x14/0x30<br /> ceph_kill_sb+0x36/0x90 [ceph]<br /> deactivate_locked_super+0x29/0x60<br /> cleanup_mnt+0xb8/0x140<br /> task_work_run+0x67/0xb0<br /> exit_to_user_mode_prepare+0x23d/0x240<br /> syscall_exit_to_user_mode+0x25/0x60<br /> do_syscall_64+0x40/0x80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7fd83dc39e9b<br /> <br /> Later the kernel will crash when iput() the inodes and dereferencing<br /> the "sb-&gt;s_master_keys", which has been released by the<br /> generic_shutdown_super().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/47x: Fix 47x syscall return crash<br /> <br /> Eddie reported that newer kernels were crashing during boot on his 476<br /> FSP2 system:<br /> <br /> kernel tried to execute user page (b7ee2000) - exploit attempt? (uid: 0)<br /> BUG: Unable to handle kernel instruction fetch<br /> Faulting instruction address: 0xb7ee2000<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> BE PAGE_SIZE=4K FSP-2<br /> Modules linked in:<br /> CPU: 0 PID: 61 Comm: mount Not tainted 6.1.55-d23900f.ppcnf-fsp2 #1<br /> Hardware name: ibm,fsp2 476fpe 0x7ff520c0 FSP-2<br /> NIP:  b7ee2000 LR: 8c008000 CTR: 00000000<br /> REGS: bffebd83 TRAP: 0400   Not tainted (6.1.55-d23900f.ppcnf-fs p2)<br /> MSR:  00000030   CR: 00001000  XER: 20000000<br /> GPR00: c00110ac bffebe63 bffebe7e bffebe88 8c008000 00001000 00000d12 b7ee2000<br /> GPR08: 00000033 00000000 00000000 c139df10 48224824 1016c314 10160000 00000000<br /> GPR16: 10160000 10160000 00000008 00000000 10160000 00000000 10160000 1017f5b0<br /> GPR24: 1017fa50 1017f4f0 1017fa50 1017f740 1017f630 00000000 00000000 1017f4f0<br /> NIP [b7ee2000] 0xb7ee2000<br /> LR [8c008000] 0x8c008000<br /> Call Trace:<br /> Instruction dump:<br /> XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX<br /> XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> The problem is in ret_from_syscall where the check for<br /> icache_44x_need_flush is done. When the flush is needed the code jumps<br /> out-of-line to do the flush, and then intends to jump back to continue<br /> the syscall return.<br /> <br /> However the branch back to label 1b doesn&amp;#39;t return to the correct<br /> location, instead branching back just prior to the return to userspace,<br /> causing bogus register values to be used by the rfi.<br /> <br /> The breakage was introduced by commit 6f76a01173cc<br /> ("powerpc/syscall: implement system call entry/exit logic in C for PPC32") which<br /> inadvertently removed the "1" label and reused it elsewhere.<br /> <br /> Fix it by adding named local labels in the correct locations. Note that<br /> the return label needs to be outside the ifdef so that CONFIG_PPC_47x=n<br /> compiles.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: pm80xx: Avoid leaking tags when processing OPC_INB_SET_CONTROLLER_CONFIG command<br /> <br /> Tags allocated for OPC_INB_SET_CONTROLLER_CONFIG command need to be freed<br /> when we receive the response.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ring-buffer: Do not attempt to read past "commit"<br /> <br /> When iterating over the ring buffer while the ring buffer is active, the<br /> writer can corrupt the reader. There&amp;#39;s barriers to help detect this and<br /> handle it, but that code missed the case where the last event was at the<br /> very end of the page and has only 4 bytes left.<br /> <br /> The checks to detect the corruption by the writer to reads needs to see the<br /> length of the event. If the length in the first 4 bytes is zero then the<br /> length is stored in the second 4 bytes. But if the writer is in the process<br /> of updating that code, there&amp;#39;s a small window where the length in the first<br /> 4 bytes could be zero even though the length is only 4 bytes. That will<br /> cause rb_event_length() to read the next 4 bytes which could happen to be off the<br /> allocated page.<br /> <br /> To protect against this, fail immediately if the next event pointer is<br /> less than 8 bytes from the end of the commit (last byte of data), as all<br /> events must be a minimum of 8 bytes anyway.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: nfc: fix races in nfc_llcp_sock_get() and nfc_llcp_sock_get_sn()<br /> <br /> Sili Luo reported a race in nfc_llcp_sock_get(), leading to UAF.<br /> <br /> Getting a reference on the socket found in a lookup while<br /> holding a lock should happen before releasing the lock.<br /> <br /> nfc_llcp_sock_get_sn() has a similar problem.<br /> <br /> Finally nfc_llcp_recv_snl() needs to make sure the socket<br /> found by nfc_llcp_sock_from_sn() does not disappear.