Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to do sanity check on curseg-&gt;alloc_type<br /> <br /> As Wenqing Liu reported in bugzilla:<br /> <br /> https://bugzilla.kernel.org/show_bug.cgi?id=215657<br /> <br /> - Overview<br /> UBSAN: array-index-out-of-bounds in fs/f2fs/segment.c:3460:2 when mount and operate a corrupted image<br /> <br /> - Reproduce<br /> tested on kernel 5.17-rc4, 5.17-rc6<br /> <br /> 1. mkdir test_crash<br /> 2. cd test_crash<br /> 3. unzip tmp2.zip<br /> 4. mkdir mnt<br /> 5. ./single_test.sh f2fs 2<br /> <br /> - Kernel dump<br /> [ 46.434454] loop0: detected capacity change from 0 to 131072<br /> [ 46.529839] F2FS-fs (loop0): Mounted with checkpoint version = 7548c2d9<br /> [ 46.738319] ================================================================================<br /> [ 46.738412] UBSAN: array-index-out-of-bounds in fs/f2fs/segment.c:3460:2<br /> [ 46.738475] index 231 is out of range for type &amp;#39;unsigned int [2]&amp;#39;<br /> [ 46.738539] CPU: 2 PID: 939 Comm: umount Not tainted 5.17.0-rc6 #1<br /> [ 46.738547] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014<br /> [ 46.738551] Call Trace:<br /> [ 46.738556] <br /> [ 46.738563] dump_stack_lvl+0x47/0x5c<br /> [ 46.738581] ubsan_epilogue+0x5/0x50<br /> [ 46.738592] __ubsan_handle_out_of_bounds+0x68/0x80<br /> [ 46.738604] f2fs_allocate_data_block+0xdff/0xe60 [f2fs]<br /> [ 46.738819] do_write_page+0xef/0x210 [f2fs]<br /> [ 46.738934] f2fs_do_write_node_page+0x3f/0x80 [f2fs]<br /> [ 46.739038] __write_node_page+0x2b7/0x920 [f2fs]<br /> [ 46.739162] f2fs_sync_node_pages+0x943/0xb00 [f2fs]<br /> [ 46.739293] f2fs_write_checkpoint+0x7bb/0x1030 [f2fs]<br /> [ 46.739405] kill_f2fs_super+0x125/0x150 [f2fs]<br /> [ 46.739507] deactivate_locked_super+0x60/0xc0<br /> [ 46.739517] deactivate_super+0x70/0xb0<br /> [ 46.739524] cleanup_mnt+0x11a/0x200<br /> [ 46.739532] __cleanup_mnt+0x16/0x20<br /> [ 46.739538] task_work_run+0x67/0xa0<br /> [ 46.739547] exit_to_user_mode_prepare+0x18c/0x1a0<br /> [ 46.739559] syscall_exit_to_user_mode+0x26/0x40<br /> [ 46.739568] do_syscall_64+0x46/0xb0<br /> [ 46.739584] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> The root cause is we missed to do sanity check on curseg-&gt;alloc_type,<br /> result in out-of-bound accessing on sbi-&gt;block_count[] array, fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> parisc: Fix non-access data TLB cache flush faults<br /> <br /> When a page is not present, we get non-access data TLB faults from<br /> the fdc and fic instructions in flush_user_dcache_range_asm and<br /> flush_user_icache_range_asm. When these occur, the cache line is<br /> not invalidated and potentially we get memory corruption. The<br /> problem was hidden by the nullification of the flush instructions.<br /> <br /> These faults also affect performance. With pa8800/pa8900 processors,<br /> there will be 32 faults per 4 KB page since the cache line is 128<br /> bytes. There will be more faults with earlier processors.<br /> <br /> The problem is fixed by using flush_cache_pages(). It does the flush<br /> using a tmp alias mapping.<br /> <br /> The flush_cache_pages() call in flush_cache_range() flushed too<br /> large a range.<br /> <br /> V2: Remove unnecessary preempt_disable() and preempt_enable() calls.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix ext4_mb_mark_bb() with flex_bg with fast_commit<br /> <br /> In case of flex_bg feature (which is by default enabled), extents for<br /> any given inode might span across blocks from two different block group.<br /> ext4_mb_mark_bb() only reads the buffer_head of block bitmap once for the<br /> starting block group, but it fails to read it again when the extent length<br /> boundary overflows to another block group. Then in this below loop it<br /> accesses memory beyond the block group bitmap buffer_head and results<br /> into a data abort.<br /> <br /> for (i = 0; i b_data) == !state)<br /> already++;<br /> <br /> This patch adds this functionality for checking block group boundary in<br /> ext4_mb_mark_bb() and update the buffer_head(bitmap_bh) for every different<br /> block group.<br /> <br /> w/o this patch, I was easily able to hit a data access abort using Power platform.<br /> <br /> <br /> [ 74.327662] EXT4-fs error (device loop3): ext4_mb_generate_buddy:1141: group 11, block bitmap and bg descriptor inconsistent: 21248 vs 23294 free clusters<br /> [ 74.533214] EXT4-fs (loop3): shut down requested (2)<br /> [ 74.536705] Aborting journal on device loop3-8.<br /> [ 74.702705] BUG: Unable to handle kernel data access on read at 0xc00000005e980000<br /> [ 74.703727] Faulting instruction address: 0xc0000000007bffb8<br /> cpu 0xd: Vector: 300 (Data Access) at [c000000015db7060]<br /> pc: c0000000007bffb8: ext4_mb_mark_bb+0x198/0x5a0<br /> lr: c0000000007bfeec: ext4_mb_mark_bb+0xcc/0x5a0<br /> sp: c000000015db7300<br /> msr: 800000000280b033<br /> dar: c00000005e980000<br /> dsisr: 40000000<br /> current = 0xc000000027af6880<br /> paca = 0xc00000003ffd5200 irqmask: 0x03 irq_happened: 0x01<br /> pid = 5167, comm = mount<br /> <br /> enter ? for help<br /> [c000000015db7380] c000000000782708 ext4_ext_clear_bb+0x378/0x410<br /> [c000000015db7400] c000000000813f14 ext4_fc_replay+0x1794/0x2000<br /> [c000000015db7580] c000000000833f7c do_one_pass+0xe9c/0x12a0<br /> [c000000015db7710] c000000000834504 jbd2_journal_recover+0x184/0x2d0<br /> [c000000015db77c0] c000000000841398 jbd2_journal_load+0x188/0x4a0<br /> [c000000015db7880] c000000000804de8 ext4_fill_super+0x2638/0x3e10<br /> [c000000015db7a40] c0000000005f8404 get_tree_bdev+0x2b4/0x350<br /> [c000000015db7ae0] c0000000007ef058 ext4_get_tree+0x28/0x40<br /> [c000000015db7b00] c0000000005f6344 vfs_get_tree+0x44/0x100<br /> [c000000015db7b70] c00000000063c408 path_mount+0xdd8/0xe70<br /> [c000000015db7c40] c00000000063c8f0 sys_mount+0x450/0x550<br /> [c000000015db7d50] c000000000035770 system_call_exception+0x4a0/0x4e0<br /> [c000000015db7e10] c00000000000c74c system_call_common+0xec/0x250

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> memstick/mspro_block: fix handling of read-only devices<br /> <br /> Use set_disk_ro to propagate the read-only state to the block layer<br /> instead of checking for it in -&gt;open and leaking a reference in case<br /> of a read-only device.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: Fix error handling in mt8183_da7219_max98357_dev_probe<br /> <br /> The device_node pointer is returned by of_parse_phandle() with refcount<br /> incremented. We should use of_node_put() on it when done.<br /> <br /> This function only calls of_node_put() in the regular path.<br /> And it will cause refcount leak in error paths.<br /> Fix this by calling of_node_put() in error handling too.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/tm: Fix more userspace r13 corruption<br /> <br /> Commit cf13435b730a ("powerpc/tm: Fix userspace r13 corruption") fixes a<br /> problem in treclaim where a SLB miss can occur on the<br /> thread_struct-&gt;ckpt_regs while SCRATCH0 is live with the saved user r13<br /> value, clobbering it with the kernel r13 and ultimately resulting in<br /> kernel r13 being stored in ckpt_regs.<br /> <br /> There is an equivalent problem in trechkpt where the user r13 value is<br /> loaded into r13 from chkpt_regs to be recheckpointed, but a SLB miss<br /> could occur on ckpt_regs accesses after that, which will result in r13<br /> being clobbered with a kernel value and that will get recheckpointed and<br /> then restored to user registers.<br /> <br /> The same memory page is accessed right before this critical window where<br /> a SLB miss could cause corruption, so hitting the bug requires the SLB<br /> entry be removed within a small window of instructions, which is<br /> possible if a SLB related MCE hits there. PAPR also permits the<br /> hypervisor to discard this SLB entry (because slb_shadow-&gt;persistent is<br /> only set to SLB_NUM_BOLTED) although it&amp;#39;s not known whether any<br /> implementations would do this (KVM does not). So this is an extremely<br /> unlikely bug, only found by inspection.<br /> <br /> Fix this by also storing user r13 in a temporary location on the kernel<br /> stack and don&amp;#39;t change the r13 register from kernel r13 until the RI=0<br /> critical section that does not fault.<br /> <br /> The SCRATCH0 change is not strictly part of the fix, it&amp;#39;s only used in<br /> the RI=0 section so it does not have the same problem as the previous<br /> SCRATCH0 bug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: imx-jpeg: Prevent decoding NV12M jpegs into single-planar buffers<br /> <br /> If the application queues an NV12M jpeg as output buffer, but then<br /> queues a single planar capture buffer, the kernel will crash with<br /> "Unable to handle kernel NULL pointer dereference" in mxc_jpeg_addrs,<br /> prevent this by finishing the job with error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs: add sanity check on allocation size<br /> <br /> ntfs_read_inode_mount invokes ntfs_malloc_nofs with zero allocation<br /> size. It triggers one BUG in the __ntfs_malloc function.<br /> <br /> Fix this by adding sanity check on ni-&gt;attr_list_size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: do not clean up repair bio if submit fails<br /> <br /> The submit helper will always run bio_endio() on the bio if it fails to<br /> submit, so cleaning up the bio just leads to a variety of use-after-free<br /> and NULL pointer dereference bugs because we race with the endio<br /> function that is cleaning up the bio. Instead just return BLK_STS_OK as<br /> the repair function has to continue to process the rest of the pages,<br /> and the endio for the repair bio will do the appropriate cleanup for the<br /> page that it was given.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Fix warning message due to adisc being flushed<br /> <br /> Fix warning message due to adisc being flushed. Linux kernel triggered a<br /> warning message where a different error code type is not matching up with<br /> the expected type. Add additional translation of one error code type to<br /> another.<br /> <br /> WARNING: CPU: 2 PID: 1131623 at drivers/scsi/qla2xxx/qla_init.c:498<br /> qla2x00_async_adisc_sp_done+0x294/0x2b0 [qla2xxx]<br /> CPU: 2 PID: 1131623 Comm: drmgr Not tainted 5.13.0-rc1-autotest #1<br /> ..<br /> GPR28: c000000aaa9c8890 c0080000079ab678 c00000140a104800 c00000002bd19000<br /> NIP [c00800000790857c] qla2x00_async_adisc_sp_done+0x294/0x2b0 [qla2xxx]<br /> LR [c008000007908578] qla2x00_async_adisc_sp_done+0x290/0x2b0 [qla2xxx]<br /> Call Trace:<br /> [c00000001cdc3620] [c008000007908578] qla2x00_async_adisc_sp_done+0x290/0x2b0 [qla2xxx] (unreliable)<br /> [c00000001cdc3710] [c0080000078f3080] __qla2x00_abort_all_cmds+0x1b8/0x580 [qla2xxx]<br /> [c00000001cdc3840] [c0080000078f589c] qla2x00_abort_all_cmds+0x34/0xd0 [qla2xxx]<br /> [c00000001cdc3880] [c0080000079153d8] qla2x00_abort_isp_cleanup+0x3f0/0x570 [qla2xxx]<br /> [c00000001cdc3920] [c0080000078fb7e8] qla2x00_remove_one+0x3d0/0x480 [qla2xxx]<br /> [c00000001cdc39b0] [c00000000071c274] pci_device_remove+0x64/0x120<br /> [c00000001cdc39f0] [c0000000007fb818] device_release_driver_internal+0x168/0x2a0<br /> [c00000001cdc3a30] [c00000000070e304] pci_stop_bus_device+0xb4/0x100<br /> [c00000001cdc3a70] [c00000000070e4f0] pci_stop_and_remove_bus_device+0x20/0x40<br /> [c00000001cdc3aa0] [c000000000073940] pci_hp_remove_devices+0x90/0x130<br /> [c00000001cdc3b30] [c0080000070704d0] disable_slot+0x38/0x90 [rpaphp] [<br /> c00000001cdc3b60] [c00000000073eb4c] power_write_file+0xcc/0x180<br /> [c00000001cdc3be0] [c0000000007354bc] pci_slot_attr_store+0x3c/0x60<br /> [c00000001cdc3c00] [c00000000055f820] sysfs_kf_write+0x60/0x80 [c00000001cdc3c20]<br /> [c00000000055df10] kernfs_fop_write_iter+0x1a0/0x290<br /> [c00000001cdc3c70] [c000000000447c4c] new_sync_write+0x14c/0x1d0<br /> [c00000001cdc3d10] [c00000000044b134] vfs_write+0x224/0x330<br /> [c00000001cdc3d60] [c00000000044b3f4] ksys_write+0x74/0x130<br /> [c00000001cdc3db0] [c00000000002df70] system_call_exception+0x150/0x2d0<br /> [c00000001cdc3e10] [c00000000000d45c] system_call_common+0xec/0x278

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Implement ref count for SRB<br /> <br /> The timeout handler and the done function are racing. When<br /> qla2x00_async_iocb_timeout() starts to run it can be preempted by the<br /> normal response path (via the firmware?). qla24xx_async_gpsc_sp_done()<br /> releases the SRB unconditionally. When scheduling back to<br /> qla2x00_async_iocb_timeout() qla24xx_async_abort_cmd() will access an freed<br /> sp-&gt;qpair pointer:<br /> <br /> qla2xxx [0000:83:00.0]-2871:0: Async-gpsc timeout - hdl=63d portid=234500 50:06:0e:80:08:77:b6:21.<br /> qla2xxx [0000:83:00.0]-2853:0: Async done-gpsc res 0, WWPN 50:06:0e:80:08:77:b6:21<br /> qla2xxx [0000:83:00.0]-2854:0: Async-gpsc OUT WWPN 20:45:00:27:f8:75:33:00 speeds=2c00 speed=0400.<br /> qla2xxx [0000:83:00.0]-28d8:0: qla24xx_handle_gpsc_event 50:06:0e:80:08:77:b6:21 DS 7 LS 6 rc 0 login 1|1 rscn 1|0 lid 5<br /> BUG: unable to handle kernel NULL pointer dereference at 0000000000000004<br /> IP: qla24xx_async_abort_cmd+0x1b/0x1c0 [qla2xxx]<br /> <br /> Obvious solution to this is to introduce a reference counter. One reference<br /> is taken for the normal code path (the &amp;#39;good&amp;#39; case) and one for the timeout<br /> path. As we always race between the normal good case and the timeout/abort<br /> handler we need to serialize it. Also we cannot assume any order between<br /> the handlers. Since this is slow path we can use proper synchronization via<br /> locks.<br /> <br /> When we are able to cancel a timer (del_timer returns 1) we know there<br /> can&amp;#39;t be any error handling in progress because the timeout handler hasn&amp;#39;t<br /> expired yet, thus we can safely decrement the refcounter by one.<br /> <br /> If we are not able to cancel the timer, we know an abort handler is<br /> running. We have to make sure we call sp-&gt;done() in the abort handlers<br /> before calling kref_put().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Fix crash during module load unload test<br /> <br /> During purex packet handling the driver was incorrectly freeing a<br /> pre-allocated structure. Fix this by skipping that entry.<br /> <br /> System crashed with the following stack during a module unload test.<br /> <br /> Call Trace:<br /> sbitmap_init_node+0x7f/0x1e0<br /> sbitmap_queue_init_node+0x24/0x150<br /> blk_mq_init_bitmaps+0x3d/0xa0<br /> blk_mq_init_tags+0x68/0x90<br /> blk_mq_alloc_map_and_rqs+0x44/0x120<br /> blk_mq_alloc_set_map_and_rqs+0x63/0x150<br /> blk_mq_alloc_tag_set+0x11b/0x230<br /> scsi_add_host_with_dma.cold+0x3f/0x245<br /> qla2x00_probe_one+0xd5a/0x1b80 [qla2xxx]<br /> <br /> Call Trace with slub_debug and debug kernel:<br /> kasan_report_invalid_free+0x50/0x80<br /> __kasan_slab_free+0x137/0x150<br /> slab_free_freelist_hook+0xc6/0x190<br /> kfree+0xe8/0x2e0<br /> qla2x00_free_device+0x3bb/0x5d0 [qla2xxx]<br /> qla2x00_remove_one+0x668/0xcf0 [qla2xxx]