Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PM: core: keep irq flags in device_pm_check_callbacks()<br /> <br /> The function device_pm_check_callbacks() can be called under the spin<br /> lock (in the reported case it happens from genpd_add_device() -&gt;<br /> dev_pm_domain_set(), when the genpd uses spinlocks rather than mutexes.<br /> <br /> However this function uncoditionally uses spin_lock_irq() /<br /> spin_unlock_irq(), thus not preserving the CPU flags. Use the<br /> irqsave/irqrestore instead.<br /> <br /> The backtrace for the reference:<br /> [ 2.752010] ------------[ cut here ]------------<br /> [ 2.756769] raw_local_irq_restore() called with IRQs enabled<br /> [ 2.762596] WARNING: CPU: 4 PID: 1 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x34/0x50<br /> [ 2.772338] Modules linked in:<br /> [ 2.775487] CPU: 4 PID: 1 Comm: swapper/0 Tainted: G S 5.17.0-rc6-00384-ge330d0d82eff-dirty #684<br /> [ 2.781384] Freeing initrd memory: 46024K<br /> [ 2.785839] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 2.785841] pc : warn_bogus_irq_restore+0x34/0x50<br /> [ 2.785844] lr : warn_bogus_irq_restore+0x34/0x50<br /> [ 2.785846] sp : ffff80000805b7d0<br /> [ 2.785847] x29: ffff80000805b7d0 x28: 0000000000000000 x27: 0000000000000002<br /> [ 2.785850] x26: ffffd40e80930b18 x25: ffff7ee2329192b8 x24: ffff7edfc9f60800<br /> [ 2.785853] x23: ffffd40e80930b18 x22: ffffd40e80930d30 x21: ffff7edfc0dffa00<br /> [ 2.785856] x20: ffff7edfc09e3768 x19: 0000000000000000 x18: ffffffffffffffff<br /> [ 2.845775] x17: 6572206f74206465 x16: 6c696166203a3030 x15: ffff80008805b4f7<br /> [ 2.853108] x14: 0000000000000000 x13: ffffd40e809550b0 x12: 00000000000003d8<br /> [ 2.860441] x11: 0000000000000148 x10: ffffd40e809550b0 x9 : ffffd40e809550b0<br /> [ 2.867774] x8 : 00000000ffffefff x7 : ffffd40e809ad0b0 x6 : ffffd40e809ad0b0<br /> [ 2.875107] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000<br /> [ 2.882440] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff7edfc03a8000<br /> [ 2.889774] Call trace:<br /> [ 2.892290] warn_bogus_irq_restore+0x34/0x50<br /> [ 2.896770] _raw_spin_unlock_irqrestore+0x94/0xa0<br /> [ 2.901690] genpd_unlock_spin+0x20/0x30<br /> [ 2.905724] genpd_add_device+0x100/0x2d0<br /> [ 2.909850] __genpd_dev_pm_attach+0xa8/0x23c<br /> [ 2.914329] genpd_dev_pm_attach_by_id+0xc4/0x190<br /> [ 2.919167] genpd_dev_pm_attach_by_name+0x3c/0xd0<br /> [ 2.924086] dev_pm_domain_attach_by_name+0x24/0x30<br /> [ 2.929102] psci_dt_attach_cpu+0x24/0x90<br /> [ 2.933230] psci_cpuidle_probe+0x2d4/0x46c<br /> [ 2.937534] platform_probe+0x68/0xe0<br /> [ 2.941304] really_probe.part.0+0x9c/0x2fc<br /> [ 2.945605] __driver_probe_device+0x98/0x144<br /> [ 2.950085] driver_probe_device+0x44/0x15c<br /> [ 2.954385] __device_attach_driver+0xb8/0x120<br /> [ 2.958950] bus_for_each_drv+0x78/0xd0<br /> [ 2.962896] __device_attach+0xd8/0x180<br /> [ 2.966843] device_initial_probe+0x14/0x20<br /> [ 2.971144] bus_probe_device+0x9c/0xa4<br /> [ 2.975092] device_add+0x380/0x88c<br /> [ 2.978679] platform_device_add+0x114/0x234<br /> [ 2.983067] platform_device_register_full+0x100/0x190<br /> [ 2.988344] psci_idle_init+0x6c/0xb0<br /> [ 2.992113] do_one_initcall+0x74/0x3a0<br /> [ 2.996060] kernel_init_freeable+0x2fc/0x384<br /> [ 3.000543] kernel_init+0x28/0x130<br /> [ 3.004132] ret_from_fork+0x10/0x20<br /> [ 3.007817] irq event stamp: 319826<br /> [ 3.011404] hardirqs last enabled at (319825): [] __up_console_sem+0x78/0x84<br /> [ 3.020332] hardirqs last disabled at (319826): [] el1_dbg+0x24/0x8c<br /> [ 3.028458] softirqs last enabled at (318312): [] _stext+0x410/0x588<br /> [ 3.036678] softirqs last disabled at (318299): [] __irq_exit_rcu+0x158/0x174<br /> [ 3.045607] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bfq: fix use-after-free in bfq_dispatch_request<br /> <br /> KASAN reports a use-after-free report when doing normal scsi-mq test<br /> <br /> [69832.239032] ==================================================================<br /> [69832.241810] BUG: KASAN: use-after-free in bfq_dispatch_request+0x1045/0x44b0<br /> [69832.243267] Read of size 8 at addr ffff88802622ba88 by task kworker/3:1H/155<br /> [69832.244656]<br /> [69832.245007] CPU: 3 PID: 155 Comm: kworker/3:1H Not tainted 5.10.0-10295-g576c6382529e #8<br /> [69832.246626] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [69832.249069] Workqueue: kblockd blk_mq_run_work_fn<br /> [69832.250022] Call Trace:<br /> [69832.250541] dump_stack+0x9b/0xce<br /> [69832.251232] ? bfq_dispatch_request+0x1045/0x44b0<br /> [69832.252243] print_address_description.constprop.6+0x3e/0x60<br /> [69832.253381] ? __cpuidle_text_end+0x5/0x5<br /> [69832.254211] ? vprintk_func+0x6b/0x120<br /> [69832.254994] ? bfq_dispatch_request+0x1045/0x44b0<br /> [69832.255952] ? bfq_dispatch_request+0x1045/0x44b0<br /> [69832.256914] kasan_report.cold.9+0x22/0x3a<br /> [69832.257753] ? bfq_dispatch_request+0x1045/0x44b0<br /> [69832.258755] check_memory_region+0x1c1/0x1e0<br /> [69832.260248] bfq_dispatch_request+0x1045/0x44b0<br /> [69832.261181] ? bfq_bfqq_expire+0x2440/0x2440<br /> [69832.262032] ? blk_mq_delay_run_hw_queues+0xf9/0x170<br /> [69832.263022] __blk_mq_do_dispatch_sched+0x52f/0x830<br /> [69832.264011] ? blk_mq_sched_request_inserted+0x100/0x100<br /> [69832.265101] __blk_mq_sched_dispatch_requests+0x398/0x4f0<br /> [69832.266206] ? blk_mq_do_dispatch_ctx+0x570/0x570<br /> [69832.267147] ? __switch_to+0x5f4/0xee0<br /> [69832.267898] blk_mq_sched_dispatch_requests+0xdf/0x140<br /> [69832.268946] __blk_mq_run_hw_queue+0xc0/0x270<br /> [69832.269840] blk_mq_run_work_fn+0x51/0x60<br /> [69832.278170] process_one_work+0x6d4/0xfe0<br /> [69832.278984] worker_thread+0x91/0xc80<br /> [69832.279726] ? __kthread_parkme+0xb0/0x110<br /> [69832.280554] ? process_one_work+0xfe0/0xfe0<br /> [69832.281414] kthread+0x32d/0x3f0<br /> [69832.282082] ? kthread_park+0x170/0x170<br /> [69832.282849] ret_from_fork+0x1f/0x30<br /> [69832.283573]<br /> [69832.283886] Allocated by task 7725:<br /> [69832.284599] kasan_save_stack+0x19/0x40<br /> [69832.285385] __kasan_kmalloc.constprop.2+0xc1/0xd0<br /> [69832.286350] kmem_cache_alloc_node+0x13f/0x460<br /> [69832.287237] bfq_get_queue+0x3d4/0x1140<br /> [69832.287993] bfq_get_bfqq_handle_split+0x103/0x510<br /> [69832.289015] bfq_init_rq+0x337/0x2d50<br /> [69832.289749] bfq_insert_requests+0x304/0x4e10<br /> [69832.290634] blk_mq_sched_insert_requests+0x13e/0x390<br /> [69832.291629] blk_mq_flush_plug_list+0x4b4/0x760<br /> [69832.292538] blk_flush_plug_list+0x2c5/0x480<br /> [69832.293392] io_schedule_prepare+0xb2/0xd0<br /> [69832.294209] io_schedule_timeout+0x13/0x80<br /> [69832.295014] wait_for_common_io.constprop.1+0x13c/0x270<br /> [69832.296137] submit_bio_wait+0x103/0x1a0<br /> [69832.296932] blkdev_issue_discard+0xe6/0x160<br /> [69832.297794] blk_ioctl_discard+0x219/0x290<br /> [69832.298614] blkdev_common_ioctl+0x50a/0x1750<br /> [69832.304715] blkdev_ioctl+0x470/0x600<br /> [69832.305474] block_ioctl+0xde/0x120<br /> [69832.306232] vfs_ioctl+0x6c/0xc0<br /> [69832.306877] __se_sys_ioctl+0x90/0xa0<br /> [69832.307629] do_syscall_64+0x2d/0x40<br /> [69832.308362] entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> [69832.309382]<br /> [69832.309701] Freed by task 155:<br /> [69832.310328] kasan_save_stack+0x19/0x40<br /> [69832.311121] kasan_set_track+0x1c/0x30<br /> [69832.311868] kasan_set_free_info+0x1b/0x30<br /> [69832.312699] __kasan_slab_free+0x111/0x160<br /> [69832.313524] kmem_cache_free+0x94/0x460<br /> [69832.314367] bfq_put_queue+0x582/0x940<br /> [69832.315112] __bfq_bfqd_reset_in_service+0x166/0x1d0<br /> [69832.317275] bfq_bfqq_expire+0xb27/0x2440<br /> [69832.318084] bfq_dispatch_request+0x697/0x44b0<br /> [69832.318991] __blk_mq_do_dispatch_sched+0x52f/0x830<br /> [69832.319984] __blk_mq_sched_dispatch_requests+0x398/0x4f0<br /> [69832.321087] blk_mq_sched_dispatch_requests+0xdf/0x140<br /> [69832.322225] __blk_mq_run_hw_queue+0xc0/0x270<br /> [69832.323114] blk_mq_run_work_fn+0x51/0x6<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwrng: cavium - fix NULL but dereferenced coccicheck error<br /> <br /> Fix following coccicheck warning:<br /> ./drivers/char/hw_random/cavium-rng-vf.c:182:17-20: ERROR:<br /> pdev is NULL but dereferenced.

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