Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubifs: Fix to add refcount once page is set private<br /> <br /> MM defined the rule [1] very clearly that once page was set with PG_private<br /> flag, we should increment the refcount in that page, also main flows like<br /> pageout(), migrate_page() will assume there is one additional page<br /> reference count if page_has_private() returns true. Otherwise, we may<br /> get a BUG in page migration:<br /> <br /> page:0000000080d05b9d refcount:-1 mapcount:0 mapping:000000005f4d82a8<br /> index:0xe2 pfn:0x14c12<br /> aops:ubifs_file_address_operations [ubifs] ino:8f1 dentry name:"f30e"<br /> flags: 0x1fffff80002405(locked|uptodate|owner_priv_1|private|node=0|<br /> zone=1|lastcpupid=0x1fffff)<br /> page dumped because: VM_BUG_ON_PAGE(page_count(page) != 0)<br /> ------------[ cut here ]------------<br /> kernel BUG at include/linux/page_ref.h:184!<br /> invalid opcode: 0000 [#1] SMP<br /> CPU: 3 PID: 38 Comm: kcompactd0 Not tainted 5.15.0-rc5<br /> RIP: 0010:migrate_page_move_mapping+0xac3/0xe70<br /> Call Trace:<br /> ubifs_migrate_page+0x22/0xc0 [ubifs]<br /> move_to_new_page+0xb4/0x600<br /> migrate_pages+0x1523/0x1cc0<br /> compact_zone+0x8c5/0x14b0<br /> kcompactd+0x2bc/0x560<br /> kthread+0x18c/0x1e0<br /> ret_from_fork+0x1f/0x30<br /> <br /> Before the time, we should make clean a concept, what does refcount means<br /> in page gotten from grab_cache_page_write_begin(). There are 2 situations:<br /> Situation 1: refcount is 3, page is created by __page_cache_alloc.<br /> TYPE_A - the write process is using this page<br /> TYPE_B - page is assigned to one certain mapping by calling<br /> __add_to_page_cache_locked()<br /> TYPE_C - page is added into pagevec list corresponding current cpu by<br /> calling lru_cache_add()<br /> Situation 2: refcount is 2, page is gotten from the mapping&amp;#39;s tree<br /> TYPE_B - page has been assigned to one certain mapping<br /> TYPE_A - the write process is using this page (by calling<br /> page_cache_get_speculative())<br /> Filesystem releases one refcount by calling put_page() in xxx_write_end(),<br /> the released refcount corresponds to TYPE_A (write task is using it). If<br /> there are any processes using a page, page migration process will skip the<br /> page by judging whether expected_page_refs() equals to page refcount.<br /> <br /> The BUG is caused by following process:<br /> PA(cpu 0) kcompactd(cpu 1)<br /> compact_zone<br /> ubifs_write_begin<br /> page_a = grab_cache_page_write_begin<br /> add_to_page_cache_lru<br /> lru_cache_add<br /> pagevec_add // put page into cpu 0&amp;#39;s pagevec<br /> (refcnf = 3, for page creation process)<br /> ubifs_write_end<br /> SetPagePrivate(page_a) // doesn&amp;#39;t increase page count !<br /> unlock_page(page_a)<br /> put_page(page_a) // refcnt = 2<br /> [...]<br /> <br /> PB(cpu 0)<br /> filemap_read<br /> filemap_get_pages<br /> add_to_page_cache_lru<br /> lru_cache_add<br /> __pagevec_lru_add // traverse all pages in cpu 0&amp;#39;s pagevec<br /> __pagevec_lru_add_fn<br /> SetPageLRU(page_a)<br /> isolate_migratepages<br /> isolate_migratepages_block<br /> get_page_unless_zero(page_a)<br /> // refcnt = 3<br /> list_add(page_a, from_list)<br /> migrate_pages(from_list)<br /> __unmap_and_move<br /> move_to_new_page<br /> ubifs_migrate_page(page_a)<br /> migrate_page_move_mapping<br /> expected_page_refs get 3<br /> (migration[1] + mapping[1] + private[1])<br /> release_pages<br /> put_page_testzero(page_a) // refcnt = 3<br /> page_ref_freeze // refcnt = 0<br /> page_ref_dec_and_test(0 - 1 = -1)<br /> page_ref_unfreeze<br /> VM_BUG_ON_PAGE(-1 != 0, page)<br /> <br /> UBIFS doesn&amp;#39;t increase the page refcount after setting private flag, which<br /> leads to page migration task believes the page is not used by any other<br /> processes, so the page is migrated. This causes concurrent accessing on<br /> page refcount between put_page() called by other process(eg. read process<br /> calls lru_cache_add) and page_ref_unfreeze() called by mi<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubifs: Fix read out-of-bounds in ubifs_wbuf_write_nolock()<br /> <br /> Function ubifs_wbuf_write_nolock() may access buf out of bounds in<br /> following process:<br /> <br /> ubifs_wbuf_write_nolock():<br /> aligned_len = ALIGN(len, 8); // Assume len = 4089, aligned_len = 4096<br /> if (aligned_len avail) ... // Not satisfy<br /> if (wbuf-&gt;used) {<br /> ubifs_leb_write() // Fill some data in avail wbuf<br /> len -= wbuf-&gt;avail; // len is still not 8-bytes aligned<br /> aligned_len -= wbuf-&gt;avail;<br /> }<br /> n = aligned_len &gt;&gt; c-&gt;max_write_shift;<br /> if (n) {<br /> n lnum, buf + written,<br /> wbuf-&gt;offs, n);<br /> // n &gt; len, read out of bounds less than 8(n-len) bytes<br /> }<br /> <br /> , which can be catched by KASAN:<br /> =========================================================<br /> BUG: KASAN: slab-out-of-bounds in ecc_sw_hamming_calculate+0x1dc/0x7d0<br /> Read of size 4 at addr ffff888105594ff8 by task kworker/u8:4/128<br /> Workqueue: writeback wb_workfn (flush-ubifs_0_0)<br /> Call Trace:<br /> kasan_report.cold+0x81/0x165<br /> nand_write_page_swecc+0xa9/0x160<br /> ubifs_leb_write+0xf2/0x1b0 [ubifs]<br /> ubifs_wbuf_write_nolock+0x421/0x12c0 [ubifs]<br /> write_head+0xdc/0x1c0 [ubifs]<br /> ubifs_jnl_write_inode+0x627/0x960 [ubifs]<br /> wb_workfn+0x8af/0xb80<br /> <br /> Function ubifs_wbuf_write_nolock() accepts that parameter &amp;#39;len&amp;#39; is not 8<br /> bytes aligned, the &amp;#39;len&amp;#39; represents the true length of buf (which is<br /> allocated in &amp;#39;ubifs_jnl_xxx&amp;#39;, eg. ubifs_jnl_write_inode), so<br /> ubifs_wbuf_write_nolock() must handle the length read from &amp;#39;buf&amp;#39; carefully<br /> to write leb safely.<br /> <br /> Fetch a reproducer in [Link].

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubifs: Fix deadlock in concurrent rename whiteout and inode writeback<br /> <br /> Following hung tasks:<br /> [ 77.028764] task:kworker/u8:4 state:D stack: 0 pid: 132<br /> [ 77.028820] Call Trace:<br /> [ 77.029027] schedule+0x8c/0x1b0<br /> [ 77.029067] mutex_lock+0x50/0x60<br /> [ 77.029074] ubifs_write_inode+0x68/0x1f0 [ubifs]<br /> [ 77.029117] __writeback_single_inode+0x43c/0x570<br /> [ 77.029128] writeback_sb_inodes+0x259/0x740<br /> [ 77.029148] wb_writeback+0x107/0x4d0<br /> [ 77.029163] wb_workfn+0x162/0x7b0<br /> <br /> [ 92.390442] task:aa state:D stack: 0 pid: 1506<br /> [ 92.390448] Call Trace:<br /> [ 92.390458] schedule+0x8c/0x1b0<br /> [ 92.390461] wb_wait_for_completion+0x82/0xd0<br /> [ 92.390469] __writeback_inodes_sb_nr+0xb2/0x110<br /> [ 92.390472] writeback_inodes_sb_nr+0x14/0x20<br /> [ 92.390476] ubifs_budget_space+0x705/0xdd0 [ubifs]<br /> [ 92.390503] do_rename.cold+0x7f/0x187 [ubifs]<br /> [ 92.390549] ubifs_rename+0x8b/0x180 [ubifs]<br /> [ 92.390571] vfs_rename+0xdb2/0x1170<br /> [ 92.390580] do_renameat2+0x554/0x770<br /> <br /> , are caused by concurrent rename whiteout and inode writeback processes:<br /> rename_whiteout(Thread 1) wb_workfn(Thread2)<br /> ubifs_rename<br /> do_rename<br /> lock_4_inodes (Hold ui_mutex)<br /> ubifs_budget_space<br /> make_free_space<br /> shrink_liability<br /> __writeback_inodes_sb_nr<br /> bdi_split_work_to_wbs (Queue new wb work)<br /> wb_do_writeback(wb work)<br /> __writeback_single_inode<br /> ubifs_write_inode<br /> LOCK(ui_mutex)<br /> ↑<br /> wb_wait_for_completion (Wait wb work)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubifs: rename_whiteout: Fix double free for whiteout_ui-&gt;data<br /> <br /> &amp;#39;whiteout_ui-&gt;data&amp;#39; will be freed twice if space budget fail for<br /> rename whiteout operation as following process:<br /> <br /> rename_whiteout<br /> dev = kmalloc<br /> whiteout_ui-&gt;data = dev<br /> kfree(whiteout_ui-&gt;data) // Free first time<br /> iput(whiteout)<br /> ubifs_free_inode<br /> kfree(ui-&gt;data) // Double free!<br /> <br /> KASAN reports:<br /> ==================================================================<br /> BUG: KASAN: double-free or invalid-free in ubifs_free_inode+0x4f/0x70<br /> Call Trace:<br /> kfree+0x117/0x490<br /> ubifs_free_inode+0x4f/0x70 [ubifs]<br /> i_callback+0x30/0x60<br /> rcu_do_batch+0x366/0xac0<br /> __do_softirq+0x133/0x57f<br /> <br /> Allocated by task 1506:<br /> kmem_cache_alloc_trace+0x3c2/0x7a0<br /> do_rename+0x9b7/0x1150 [ubifs]<br /> ubifs_rename+0x106/0x1f0 [ubifs]<br /> do_syscall_64+0x35/0x80<br /> <br /> Freed by task 1506:<br /> kfree+0x117/0x490<br /> do_rename.cold+0x53/0x8a [ubifs]<br /> ubifs_rename+0x106/0x1f0 [ubifs]<br /> do_syscall_64+0x35/0x80<br /> <br /> The buggy address belongs to the object at ffff88810238bed8 which<br /> belongs to the cache kmalloc-8 of size 8<br /> ==================================================================<br /> <br /> Let ubifs_free_inode() free &amp;#39;whiteout_ui-&gt;data&amp;#39;. BTW, delete unused<br /> assignment &amp;#39;whiteout_ui-&gt;data_len = 0&amp;#39;, process &amp;#39;ubifs_evict_inode()<br /> -&gt; ubifs_jnl_delete_inode() -&gt; ubifs_jnl_write_inode()&amp;#39; doesn&amp;#39;t need it<br /> (because &amp;#39;inc_nlink(whiteout)&amp;#39; won&amp;#39;t be excuted by &amp;#39;goto out_release&amp;#39;,<br /> and the nlink of whiteout inode is 0).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86/mmu: Zap _all_ roots when unmapping gfn range in TDP MMU<br /> <br /> Zap both valid and invalid roots when zapping/unmapping a gfn range, as<br /> KVM must ensure it holds no references to the freed page after returning<br /> from the unmap operation. Most notably, the TDP MMU doesn&amp;#39;t zap invalid<br /> roots in mmu_notifier callbacks. This leads to use-after-free and other<br /> issues if the mmu_notifier runs to completion while an invalid root<br /> zapper yields as KVM fails to honor the requirement that there must be<br /> _no_ references to the page after the mmu_notifier returns.<br /> <br /> The bug is most easily reproduced by hacking KVM to cause a collision<br /> between set_nx_huge_pages() and kvm_mmu_notifier_release(), but the bug<br /> exists between kvm_mmu_notifier_invalidate_range_start() and memslot<br /> updates as well. Invalidating a root ensures pages aren&amp;#39;t accessible by<br /> the guest, and KVM won&amp;#39;t read or write page data itself, but KVM will<br /> trigger e.g. kvm_set_pfn_dirty() when zapping SPTEs, and thus completing<br /> a zap of an invalid root _after_ the mmu_notifier returns is fatal.<br /> <br /> WARNING: CPU: 24 PID: 1496 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:173 [kvm]<br /> RIP: 0010:kvm_is_zone_device_pfn+0x96/0xa0 [kvm]<br /> Call Trace:<br /> <br /> kvm_set_pfn_dirty+0xa8/0xe0 [kvm]<br /> __handle_changed_spte+0x2ab/0x5e0 [kvm]<br /> __handle_changed_spte+0x2ab/0x5e0 [kvm]<br /> __handle_changed_spte+0x2ab/0x5e0 [kvm]<br /> zap_gfn_range+0x1f3/0x310 [kvm]<br /> kvm_tdp_mmu_zap_invalidated_roots+0x50/0x90 [kvm]<br /> kvm_mmu_zap_all_fast+0x177/0x1a0 [kvm]<br /> set_nx_huge_pages+0xb4/0x190 [kvm]<br /> param_attr_store+0x70/0x100<br /> module_attr_store+0x19/0x30<br /> kernfs_fop_write_iter+0x119/0x1b0<br /> new_sync_write+0x11c/0x1b0<br /> vfs_write+0x1cc/0x270<br /> ksys_write+0x5f/0xe0<br /> do_syscall_64+0x38/0xc0<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/kasan: Fix early region not updated correctly<br /> <br /> The shadow&amp;#39;s page table is not updated when PTE_RPN_SHIFT is 24<br /> and PAGE_SHIFT is 12. It not only causes false positives but<br /> also false negative as shown the following text.<br /> <br /> Fix it by bringing the logic of kasan_early_shadow_page_entry here.<br /> <br /> 1. False Positive:<br /> ==================================================================<br /> BUG: KASAN: vmalloc-out-of-bounds in pcpu_alloc+0x508/0xa50<br /> Write of size 16 at addr f57f3be0 by task swapper/0/1<br /> <br /> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.0-12267-gdebe436e77c7 #1<br /> Call Trace:<br /> [c80d1c20] [c07fe7b8] dump_stack_lvl+0x4c/0x6c (unreliable)<br /> [c80d1c40] [c02ff668] print_address_description.constprop.0+0x88/0x300<br /> [c80d1c70] [c02ff45c] kasan_report+0x1ec/0x200<br /> [c80d1cb0] [c0300b20] kasan_check_range+0x160/0x2f0<br /> [c80d1cc0] [c03018a4] memset+0x34/0x90<br /> [c80d1ce0] [c0280108] pcpu_alloc+0x508/0xa50<br /> [c80d1d40] [c02fd7bc] __kmem_cache_create+0xfc/0x570<br /> [c80d1d70] [c0283d64] kmem_cache_create_usercopy+0x274/0x3e0<br /> [c80d1db0] [c2036580] init_sd+0xc4/0x1d0<br /> [c80d1de0] [c00044a0] do_one_initcall+0xc0/0x33c<br /> [c80d1eb0] [c2001624] kernel_init_freeable+0x2c8/0x384<br /> [c80d1ef0] [c0004b14] kernel_init+0x24/0x170<br /> [c80d1f10] [c001b26c] ret_from_kernel_thread+0x5c/0x64<br /> <br /> Memory state around the buggy address:<br /> f57f3a80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> f57f3b00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> &gt;f57f3b80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ^<br /> f57f3c00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> f57f3c80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ==================================================================<br /> <br /> 2. False Negative (with KASAN tests):<br /> ==================================================================<br /> Before fix:<br /> ok 45 - kmalloc_double_kzfree<br /> # vmalloc_oob: EXPECTATION FAILED at lib/test_kasan.c:1039<br /> KASAN failure expected in "((volatile char *)area)[3100]", but none occurred<br /> not ok 46 - vmalloc_oob<br /> not ok 1 - kasan<br /> <br /> ==================================================================<br /> After fix:<br /> ok 1 - kasan

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> video: fbdev: cirrusfb: check pixclock to avoid divide by zero<br /> <br /> Do a sanity check on pixclock value to avoid divide by zero.<br /> <br /> If the pixclock value is zero, the cirrusfb driver will round up<br /> pixclock to get the derived frequency as close to maxclock as<br /> possible.<br /> <br /> Syzkaller reported a divide error in cirrusfb_check_pixclock.<br /> <br /> divide error: 0000 [#1] SMP KASAN PTI<br /> CPU: 0 PID: 14938 Comm: cirrusfb_test Not tainted 5.15.0-rc6 #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2<br /> RIP: 0010:cirrusfb_check_var+0x6f1/0x1260<br /> <br /> Call Trace:<br /> fb_set_var+0x398/0xf90<br /> do_fb_ioctl+0x4b8/0x6f0<br /> fb_ioctl+0xeb/0x130<br /> __x64_sys_ioctl+0x19d/0x220<br /> do_syscall_64+0x3a/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> video: fbdev: nvidiafb: Use strscpy() to prevent buffer overflow<br /> <br /> Coverity complains of a possible buffer overflow. However,<br /> given the &amp;#39;static&amp;#39; scope of nvidia_setup_i2c_bus() it looks<br /> like that can&amp;#39;t happen after examiniing the call sites.<br /> <br /> CID 19036 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW)<br /> 1. fixed_size_dest: You might overrun the 48-character fixed-size string<br /> chan-&gt;adapter.name by copying name without checking the length.<br /> 2. parameter_as_source: Note: This defect has an elevated risk because the<br /> source argument is a parameter of the current function.<br /> 89 strcpy(chan-&gt;adapter.name, name);<br /> <br /> Fix this warning by using strscpy() which will silence the warning and<br /> prevent any future buffer overflows should the names used to identify the<br /> channel become much longer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: davinci: da850-evm: Avoid NULL pointer dereference<br /> <br /> With newer versions of GCC, there is a panic in da850_evm_config_emac()<br /> when booting multi_v5_defconfig in QEMU under the palmetto-bmc machine:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 00000020<br /> pgd = (ptrval)<br /> [00000020] *pgd=00000000<br /> Internal error: Oops: 5 [#1] PREEMPT ARM<br /> Modules linked in:<br /> CPU: 0 PID: 1 Comm: swapper Not tainted 5.15.0 #1<br /> Hardware name: Generic DT based system<br /> PC is at da850_evm_config_emac+0x1c/0x120<br /> LR is at do_one_initcall+0x50/0x1e0<br /> <br /> The emac_pdata pointer in soc_info is NULL because davinci_soc_info only<br /> gets populated on davinci machines but da850_evm_config_emac() is called<br /> on all machines via device_initcall().<br /> <br /> Move the rmii_en assignment below the machine check so that it is only<br /> dereferenced when running on a supported SoC.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/set_memory: Avoid spinlock recursion in change_page_attr()<br /> <br /> Commit 1f9ad21c3b38 ("powerpc/mm: Implement set_memory() routines")<br /> included a spin_lock() to change_page_attr() in order to<br /> safely perform the three step operations. But then<br /> commit 9f7853d7609d ("powerpc/mm: Fix set_memory_*() against<br /> concurrent accesses") modify it to use pte_update() and do<br /> the operation safely against concurrent access.<br /> <br /> In the meantime, Maxime reported some spinlock recursion.<br /> <br /> [ 15.351649] BUG: spinlock recursion on CPU#0, kworker/0:2/217<br /> [ 15.357540] lock: init_mm+0x3c/0x420, .magic: dead4ead, .owner: kworker/0:2/217, .owner_cpu: 0<br /> [ 15.366563] CPU: 0 PID: 217 Comm: kworker/0:2 Not tainted 5.15.0+ #523<br /> [ 15.373350] Workqueue: events do_free_init<br /> [ 15.377615] Call Trace:<br /> [ 15.380232] [e4105ac0] [800946a4] do_raw_spin_lock+0xf8/0x120 (unreliable)<br /> [ 15.387340] [e4105ae0] [8001f4ec] change_page_attr+0x40/0x1d4<br /> [ 15.393413] [e4105b10] [801424e0] __apply_to_page_range+0x164/0x310<br /> [ 15.400009] [e4105b60] [80169620] free_pcp_prepare+0x1e4/0x4a0<br /> [ 15.406045] [e4105ba0] [8016c5a0] free_unref_page+0x40/0x2b8<br /> [ 15.411979] [e4105be0] [8018724c] kasan_depopulate_vmalloc_pte+0x6c/0x94<br /> [ 15.418989] [e4105c00] [801424e0] __apply_to_page_range+0x164/0x310<br /> [ 15.425451] [e4105c50] [80187834] kasan_release_vmalloc+0xbc/0x134<br /> [ 15.431898] [e4105c70] [8015f7a8] __purge_vmap_area_lazy+0x4e4/0xdd8<br /> [ 15.438560] [e4105d30] [80160d10] _vm_unmap_aliases.part.0+0x17c/0x24c<br /> [ 15.445283] [e4105d60] [801642d0] __vunmap+0x2f0/0x5c8<br /> [ 15.450684] [e4105db0] [800e32d0] do_free_init+0x68/0x94<br /> [ 15.456181] [e4105dd0] [8005d094] process_one_work+0x4bc/0x7b8<br /> [ 15.462283] [e4105e90] [8005d614] worker_thread+0x284/0x6e8<br /> [ 15.468227] [e4105f00] [8006aaec] kthread+0x1f0/0x210<br /> [ 15.473489] [e4105f40] [80017148] ret_from_kernel_thread+0x14/0x1c<br /> <br /> Remove the read / modify / write sequence to make the operation atomic<br /> and remove the spin_lock() in change_page_attr().<br /> <br /> To do the operation atomically, we can&amp;#39;t use pte modification helpers<br /> anymore. Because all platforms have different combination of bits, it<br /> is not easy to use those bits directly. But all have the<br /> _PAGE_KERNEL_{RO/ROX/RW/RWX} set of flags. All we need it to compare<br /> two sets to know which bits are set or cleared.<br /> <br /> For instance, by comparing _PAGE_KERNEL_ROX and _PAGE_KERNEL_RO you<br /> know which bit gets cleared and which bit get set when changing exec<br /> permission.

A Broken Authorization schema exists where any authenticated user could download IOA script and configuration files if the URL is known.

A Credential Disclosure vulnerability exists where an administrator could extract the stored SMTP account credentials due to lack of encryption.