Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: qcom: ipq8074: fix PCI-E clock oops<br /> <br /> Fix PCI-E clock related kernel oops that are caused by a missing clock<br /> parent.<br /> <br /> pcie0_rchng_clk_src has num_parents set to 2 but only one parent is<br /> actually set via parent_hws, it should also have "XO" defined.<br /> This will cause the kernel to panic on a NULL pointer in<br /> clk_core_get_parent_by_index().<br /> <br /> So, to fix this utilize clk_parent_data to provide gcc_xo_gpll0 parent<br /> data.<br /> Since there is already an existing static const char * const gcc_xo_gpll0[]<br /> used to provide the same parents via parent_names convert those users to<br /> clk_parent_data as well.<br /> <br /> Without this earlycon is needed to even catch the OOPS as it will reset<br /> the board before serial is initialized with the following:<br /> <br /> [ 0.232279] Unable to handle kernel paging request at virtual address 0000a00000000000<br /> [ 0.232322] Mem abort info:<br /> [ 0.239094] ESR = 0x96000004<br /> [ 0.241778] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 0.244908] SET = 0, FnV = 0<br /> [ 0.250377] EA = 0, S1PTW = 0<br /> [ 0.253236] FSC = 0x04: level 0 translation fault<br /> [ 0.256277] Data abort info:<br /> [ 0.261141] ISV = 0, ISS = 0x00000004<br /> [ 0.264262] CM = 0, WnR = 0<br /> [ 0.267820] [0000a00000000000] address between user and kernel address ranges<br /> [ 0.270954] Internal error: Oops: 96000004 [#1] SMP<br /> [ 0.278067] Modules linked in:<br /> [ 0.282751] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.15.10 #0<br /> [ 0.285882] Hardware name: Xiaomi AX3600 (DT)<br /> [ 0.292043] pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 0.296299] pc : clk_core_get_parent_by_index+0x68/0xec<br /> [ 0.303067] lr : __clk_register+0x1d8/0x820<br /> [ 0.308273] sp : ffffffc01111b7d0<br /> [ 0.312438] x29: ffffffc01111b7d0 x28: 0000000000000000 x27: 0000000000000040<br /> [ 0.315919] x26: 0000000000000002 x25: 0000000000000000 x24: ffffff8000308800<br /> [ 0.323037] x23: ffffff8000308850 x22: ffffff8000308880 x21: ffffff8000308828<br /> [ 0.330155] x20: 0000000000000028 x19: ffffff8000309700 x18: 0000000000000020<br /> [ 0.337272] x17: 000000005cc86990 x16: 0000000000000004 x15: ffffff80001d9d0a<br /> [ 0.344391] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000006<br /> [ 0.351508] x11: 0000000000000003 x10: 0101010101010101 x9 : 0000000000000000<br /> [ 0.358626] x8 : 7f7f7f7f7f7f7f7f x7 : 6468626f5e626266 x6 : 17000a3a403c1b06<br /> [ 0.365744] x5 : 061b3c403a0a0017 x4 : 0000000000000000 x3 : 0000000000000001<br /> [ 0.372863] x2 : 0000a00000000000 x1 : 0000000000000001 x0 : ffffff8000309700<br /> [ 0.379982] Call trace:<br /> [ 0.387091] clk_core_get_parent_by_index+0x68/0xec<br /> [ 0.389351] __clk_register+0x1d8/0x820<br /> [ 0.394210] devm_clk_hw_register+0x5c/0xe0<br /> [ 0.398030] devm_clk_register_regmap+0x44/0x8c<br /> [ 0.402198] qcom_cc_really_probe+0x17c/0x1d0<br /> [ 0.406711] qcom_cc_probe+0x34/0x44<br /> [ 0.411224] gcc_ipq8074_probe+0x18/0x30<br /> [ 0.414869] platform_probe+0x68/0xe0<br /> [ 0.418776] really_probe.part.0+0x9c/0x30c<br /> [ 0.422336] __driver_probe_device+0x98/0x144<br /> [ 0.426329] driver_probe_device+0x44/0x11c<br /> [ 0.430842] __device_attach_driver+0xb4/0x120<br /> [ 0.434836] bus_for_each_drv+0x68/0xb0<br /> [ 0.439349] __device_attach+0xb0/0x170<br /> [ 0.443081] device_initial_probe+0x14/0x20<br /> [ 0.446901] bus_probe_device+0x9c/0xa4<br /> [ 0.451067] device_add+0x35c/0x834<br /> [ 0.454886] of_device_add+0x54/0x64<br /> [ 0.458360] of_platform_device_create_pdata+0xc0/0x100<br /> [ 0.462181] of_platform_bus_create+0x114/0x370<br /> [ 0.467128] of_platform_bus_create+0x15c/0x370<br /> [ 0.471641] of_platform_populate+0x50/0xcc<br /> [ 0.476155] of_platform_default_populate_init+0xa8/0xc8<br /> [ 0.480324] do_one_initcall+0x50/0x1b0<br /> [ 0.485877] kernel_init_freeable+0x234/0x29c<br /> [ 0.489436] kernel_init+0x24/0x120<br /> [ 0.493948] ret_from_fork+0x10/0x20<br /> [ 0.497253] Code: d50323bf d65f03c0 f94002a2 b4000302 (f9400042)<br /> [ 0.501079] ---[ end trace 4ca7e1129da2abce ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpu: host1x: Fix a memory leak in &amp;#39;host1x_remove()&amp;#39;<br /> <br /> Add a missing &amp;#39;host1x_channel_list_free()&amp;#39; call in the remove function,<br /> as already done in the error handling path of the probe function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udmabuf: validate ubuf-&gt;pagecount<br /> <br /> Syzbot has reported GPF in sg_alloc_append_table_from_pages(). The<br /> problem was in ubuf-&gt;pages == ZERO_PTR.<br /> <br /> ubuf-&gt;pagecount is calculated from arguments passed from user-space. If<br /> user creates udmabuf with list.size == 0 then ubuf-&gt;pagecount will be<br /> also equal to zero; it causes kmalloc_array() to return ZERO_PTR.<br /> <br /> Fix it by validating ubuf-&gt;pagecount before passing it to<br /> kmalloc_array().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: soc-compress: prevent the potentially use of null pointer<br /> <br /> There is one call trace that snd_soc_register_card()<br /> -&gt;snd_soc_bind_card()-&gt;soc_init_pcm_runtime()<br /> -&gt;snd_soc_dai_compress_new()-&gt;snd_soc_new_compress().<br /> In the trace the &amp;#39;codec_dai&amp;#39; transfers from card-&gt;dai_link,<br /> and we can see from the snd_soc_add_pcm_runtime() in<br /> snd_soc_bind_card() that, if value of card-&gt;dai_link-&gt;num_codecs<br /> is 0, then &amp;#39;codec_dai&amp;#39; could be null pointer caused<br /> by index out of bound in &amp;#39;asoc_rtd_to_codec(rtd, 0)&amp;#39;.<br /> And snd_soc_register_card() is called by various platforms.<br /> Therefore, it is better to add the check in the case of misusing.<br /> And because &amp;#39;cpu_dai&amp;#39; has already checked in soc_init_pcm_runtime(),<br /> there is no need to check again.<br /> Adding the check as follow, then if &amp;#39;codec_dai&amp;#39; is null,<br /> snd_soc_new_compress() will not pass through the check<br /> &amp;#39;if (playback + capture != 1)&amp;#39;, avoiding the leftover use of<br /> &amp;#39;codec_dai&amp;#39;.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: qcom: rpmpd: Check for null return of devm_kcalloc<br /> <br /> Because of the possible failure of the allocation, data-&gt;domains might<br /> be NULL pointer and will cause the dereference of the NULL pointer<br /> later.<br /> Therefore, it might be better to check it and directly return -ENOMEM<br /> without releasing data manually if fails, because the comment of the<br /> devm_kmalloc() says "Memory allocated with this function is<br /> automatically freed on driver detach.".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> video: fbdev: smscufx: Fix null-ptr-deref in ufx_usb_probe()<br /> <br /> I got a null-ptr-deref report:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> ...<br /> RIP: 0010:fb_destroy_modelist+0x38/0x100<br /> ...<br /> Call Trace:<br /> ufx_usb_probe.cold+0x2b5/0xac1 [smscufx]<br /> usb_probe_interface+0x1aa/0x3c0 [usbcore]<br /> really_probe+0x167/0x460<br /> ...<br /> ret_from_fork+0x1f/0x30<br /> <br /> If fb_alloc_cmap() fails in ufx_usb_probe(), fb_destroy_modelist() will<br /> be called to destroy modelist in the error handling path. But modelist<br /> has not been initialized yet, so it will result in null-ptr-deref.<br /> <br /> Initialize modelist before calling fb_alloc_cmap() to fix this bug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ath5k: fix OOB in ath5k_eeprom_read_pcal_info_5111<br /> <br /> The bug was found during fuzzing. Stacktrace locates it in<br /> ath5k_eeprom_convert_pcal_info_5111.<br /> When none of the curve is selected in the loop, idx can go<br /> up to AR5K_EEPROM_N_PD_CURVES. The line makes pd out of bound.<br /> pd = &amp;chinfo[pier].pd_curves[idx];<br /> <br /> There are many OOB writes using pd later in the code. So I<br /> added a sanity check for idx. Checks for other loops involving<br /> AR5K_EEPROM_N_PD_CURVES are not needed as the loop index is not<br /> used outside the loops.<br /> <br /> The patch is NOT tested with real device.<br /> <br /> The following is the fuzzing report<br /> <br /> BUG: KASAN: slab-out-of-bounds in ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]<br /> Write of size 1 at addr ffff8880174a4d60 by task modprobe/214<br /> <br /> CPU: 0 PID: 214 Comm: modprobe Not tainted 5.6.0 #1<br /> Call Trace:<br /> dump_stack+0x76/0xa0<br /> print_address_description.constprop.0+0x16/0x200<br /> ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]<br /> ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]<br /> __kasan_report.cold+0x37/0x7c<br /> ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]<br /> kasan_report+0xe/0x20<br /> ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]<br /> ? apic_timer_interrupt+0xa/0x20<br /> ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k]<br /> ? ath5k_pci_eeprom_read+0x228/0x3c0 [ath5k]<br /> ath5k_eeprom_init+0x2513/0x6290 [ath5k]<br /> ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k]<br /> ? usleep_range+0xb8/0x100<br /> ? apic_timer_interrupt+0xa/0x20<br /> ? ath5k_eeprom_read_pcal_info_2413+0x2f20/0x2f20 [ath5k]<br /> ath5k_hw_init+0xb60/0x1970 [ath5k]<br /> ath5k_init_ah+0x6fe/0x2530 [ath5k]<br /> ? kasprintf+0xa6/0xe0<br /> ? ath5k_stop+0x140/0x140 [ath5k]<br /> ? _dev_notice+0xf6/0xf6<br /> ? apic_timer_interrupt+0xa/0x20<br /> ath5k_pci_probe.cold+0x29a/0x3d6 [ath5k]<br /> ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k]<br /> ? mutex_lock+0x89/0xd0<br /> ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k]<br /> local_pci_probe+0xd3/0x160<br /> pci_device_probe+0x23f/0x3e0<br /> ? pci_device_remove+0x280/0x280<br /> ? pci_device_remove+0x280/0x280<br /> really_probe+0x209/0x5d0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubi: Fix race condition between ctrl_cdev_ioctl and ubi_cdev_ioctl<br /> <br /> Hulk Robot reported a KASAN report about use-after-free:<br /> ==================================================================<br /> BUG: KASAN: use-after-free in __list_del_entry_valid+0x13d/0x160<br /> Read of size 8 at addr ffff888035e37d98 by task ubiattach/1385<br /> [...]<br /> Call Trace:<br /> klist_dec_and_del+0xa7/0x4a0<br /> klist_put+0xc7/0x1a0<br /> device_del+0x4d4/0xed0<br /> cdev_device_del+0x1a/0x80<br /> ubi_attach_mtd_dev+0x2951/0x34b0 [ubi]<br /> ctrl_cdev_ioctl+0x286/0x2f0 [ubi]<br /> <br /> Allocated by task 1414:<br /> device_add+0x60a/0x18b0<br /> cdev_device_add+0x103/0x170<br /> ubi_create_volume+0x1118/0x1a10 [ubi]<br /> ubi_cdev_ioctl+0xb7f/0x1ba0 [ubi]<br /> <br /> Freed by task 1385:<br /> cdev_device_del+0x1a/0x80<br /> ubi_remove_volume+0x438/0x6c0 [ubi]<br /> ubi_cdev_ioctl+0xbf4/0x1ba0 [ubi]<br /> [...]<br /> ==================================================================<br /> <br /> The lock held by ctrl_cdev_ioctl is ubi_devices_mutex, but the lock held<br /> by ubi_cdev_ioctl is ubi-&gt;device_mutex. Therefore, the two locks can be<br /> concurrent.<br /> <br /> ctrl_cdev_ioctl contains two operations: ubi_attach and ubi_detach.<br /> ubi_detach is bug-free because it uses reference counting to prevent<br /> concurrency. However, uif_init and uif_close in ubi_attach may race with<br /> ubi_cdev_ioctl.<br /> <br /> uif_init will race with ubi_cdev_ioctl as in the following stack.<br /> cpu1 cpu2 cpu3<br /> _______________________|________________________|______________________<br /> ctrl_cdev_ioctl<br /> ubi_attach_mtd_dev<br /> uif_init<br /> ubi_cdev_ioctl<br /> ubi_create_volume<br /> cdev_device_add<br /> ubi_add_volume<br /> // sysfs exist<br /> kill_volumes<br /> ubi_cdev_ioctl<br /> ubi_remove_volume<br /> cdev_device_del<br /> // first free<br /> ubi_free_volume<br /> cdev_del<br /> // double free<br /> cdev_device_del<br /> <br /> And uif_close will race with ubi_cdev_ioctl as in the following stack.<br /> cpu1 cpu2 cpu3<br /> _______________________|________________________|______________________<br /> ctrl_cdev_ioctl<br /> ubi_attach_mtd_dev<br /> uif_init<br /> ubi_cdev_ioctl<br /> ubi_create_volume<br /> cdev_device_add<br /> ubi_debugfs_init_dev<br /> //error goto out_uif;<br /> uif_close<br /> kill_volumes<br /> ubi_cdev_ioctl<br /> ubi_remove_volume<br /> cdev_device_del<br /> // first free<br /> ubi_free_volume<br /> // double free<br /> <br /> The cause of this problem is that commit 714fb87e8bc0 make device<br /> "available" before it becomes accessible via sysfs. Therefore, we<br /> roll back the modification. We will fix the race condition between<br /> ubi device creation and udev by removing ubi_get_device in<br /> vol_attribute_show and dev_attribute_show.This avoids accessing<br /> uninitialized ubi_devices[ubi_num].<br /> <br /> ubi_get_device is used to prevent devices from being deleted during<br /> sysfs execution. However, now kernfs ensures that devices will not<br /> be deleted before all reference counting are released.<br /> The key process is shown in the following stack.<br /> <br /> device_del<br /> device_remove_attrs<br /> device_remove_groups<br /> sysfs_remove_groups<br /> sysfs_remove_group<br /> remove_files<br /> kernfs_remove_by_name<br /> kernfs_remove_by_name_ns<br /> __kernfs_remove<br /> kernfs_drain

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).