Vulnerabilities

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]

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 /> video: fbdev: sm712fb: Fix crash in smtcfb_write()<br /> <br /> When the sm712fb driver writes three bytes to the framebuffer, the<br /> driver will crash:<br /> <br /> BUG: unable to handle page fault for address: ffffc90001ffffff<br /> RIP: 0010:smtcfb_write+0x454/0x5b0<br /> Call Trace:<br /> vfs_write+0x291/0xd60<br /> ? do_sys_openat2+0x27d/0x350<br /> ? __fget_light+0x54/0x340<br /> ksys_write+0xce/0x190<br /> do_syscall_64+0x43/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> Fix it by removing the open-coded endianness fixup-code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: imx-jpeg: fix a bug of accessing array out of bounds<br /> <br /> When error occurs in parsing jpeg, the slot isn&amp;#39;t acquired yet, it may<br /> be the default value MXC_MAX_SLOTS.<br /> If the driver access the slot using the incorrect slot number, it will<br /> access array out of bounds.<br /> The result is the driver will change num_domains, which follows<br /> slot_data in struct mxc_jpeg_dev.<br /> Then the driver won&amp;#39;t detach the pm domain at rmmod, which will lead to<br /> kernel panic when trying to insmod again.

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 double complete bio on errors during compressed reads<br /> <br /> I hit some weird panics while fixing up the error handling from<br /> btrfs_lookup_bio_sums(). Turns out the compression path will complete<br /> the bio we use if we set up any of the compression bios and then return<br /> an error, and then btrfs_submit_data_bio() will also call bio_endio() on<br /> the bio.<br /> <br /> Fix this by making btrfs_submit_compressed_read() responsible for<br /> calling bio_endio() on the bio if there are any errors. Currently it<br /> was only doing it if we created the compression bios, otherwise it was<br /> depending on btrfs_submit_data_bio() to do the right thing. This<br /> creates the above problem, so fix up btrfs_submit_compressed_read() to<br /> always call bio_endio() in case of an error, and then simply return from<br /> btrfs_submit_data_bio() if we had to call<br /> btrfs_submit_compressed_read().

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 /> XArray: Fix xas_create_range() when multi-order entry present<br /> <br /> If there is already an entry present that is of order &gt;= XA_CHUNK_SHIFT<br /> when we call xas_create_range(), xas_create_range() will misinterpret<br /> that entry as a node and dereference xa_node-&gt;parent, generally leading<br /> to a crash that looks something like this:<br /> <br /> general protection fault, probably for non-canonical address 0xdffffc0000000001:<br /> 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> CPU: 0 PID: 32 Comm: khugepaged Not tainted 5.17.0-rc8-syzkaller-00003-g56e337f2cf13 #0<br /> RIP: 0010:xa_parent_locked include/linux/xarray.h:1207 [inline]<br /> RIP: 0010:xas_create_range+0x2d9/0x6e0 lib/xarray.c:725<br /> <br /> It&amp;#39;s deterministically reproducable once you know what the problem is,<br /> but producing it in a live kernel requires khugepaged to hit a race.<br /> While the problem has been present since xas_create_range() was<br /> introduced, I&amp;#39;m not aware of a way to hit it before the page cache was<br /> converted to use multi-index entries.