Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: Return non-zero value from tipc_udp_addr2str() on error<br /> <br /> tipc_udp_addr2str() should return non-zero value if the UDP media<br /> address is invalid. Otherwise, a buffer overflow access can occur in<br /> tipc_media_addr_printf(). Fix this by returning 1 on an invalid UDP<br /> media address.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/iwcm: Fix a use-after-free related to destroying CM IDs<br /> <br /> iw_conn_req_handler() associates a new struct rdma_id_private (conn_id) with<br /> an existing struct iw_cm_id (cm_id) as follows:<br /> <br /> conn_id-&gt;cm_id.iw = cm_id;<br /> cm_id-&gt;context = conn_id;<br /> cm_id-&gt;cm_handler = cma_iw_handler;<br /> <br /> rdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Make<br /> sure that cm_work_handler() does not trigger a use-after-free by only<br /> freeing of the struct rdma_id_private after all pending work has finished.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: validate nvme_local_port correctly<br /> <br /> The driver load failed with error message,<br /> <br /> qla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffef<br /> <br /> and with a kernel crash,<br /> <br /> BUG: unable to handle kernel NULL pointer dereference at 0000000000000070<br /> Workqueue: events_unbound qla_register_fcport_fn [qla2xxx]<br /> RIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc]<br /> RSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000<br /> RDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000<br /> RBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030<br /> R10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4<br /> R13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8<br /> FS: 0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0<br /> Call Trace:<br /> qla_nvme_register_remote+0xeb/0x1f0 [qla2xxx]<br /> ? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx]<br /> qla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx]<br /> qla_register_fcport_fn+0x54/0xc0 [qla2xxx]<br /> <br /> Exit the qla_nvme_register_remote() function when qla_nvme_register_hba()<br /> fails and correctly validate nvme_local_port.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Complete command early within lock<br /> <br /> A crash was observed while performing NPIV and FW reset,<br /> <br /> BUG: kernel NULL pointer dereference, address: 000000000000001c<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 1 PREEMPT_RT SMP NOPTI<br /> RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0<br /> RSP: 0018:ffffc90026f47b88 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000002<br /> RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8881041130d0<br /> RBP: ffff8881041130d0 R08: 0000000000000000 R09: 0000000000000034<br /> R10: ffffc90026f47c48 R11: 0000000000000031 R12: 0000000000000000<br /> R13: 0000000000000000 R14: ffff8881565e4a20 R15: 0000000000000000<br /> FS: 00007f4c69ed3d00(0000) GS:ffff889faac80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000000000001c CR3: 0000000288a50002 CR4: 00000000007706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __die_body+0x1a/0x60<br /> ? page_fault_oops+0x16f/0x4a0<br /> ? do_user_addr_fault+0x174/0x7f0<br /> ? exc_page_fault+0x69/0x1a0<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? dma_direct_unmap_sg+0x51/0x1e0<br /> ? preempt_count_sub+0x96/0xe0<br /> qla2xxx_qpair_sp_free_dma+0x29f/0x3b0 [qla2xxx]<br /> qla2xxx_qpair_sp_compl+0x60/0x80 [qla2xxx]<br /> __qla2x00_abort_all_cmds+0xa2/0x450 [qla2xxx]<br /> <br /> The command completion was done early while aborting the commands in driver<br /> unload path but outside lock to avoid the WARN_ON condition of performing<br /> dma_free_attr within the lock. However this caused race condition while<br /> command completion via multiple paths causing system crash.<br /> <br /> Hence complete the command early in unload path but within the lock to<br /> avoid race condition.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Fix for possible memory corruption<br /> <br /> Init Control Block is dereferenced incorrectly. Correctly dereference ICB

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: During vport delete send async logout explicitly<br /> <br /> During vport delete, it is observed that during unload we hit a crash<br /> because of stale entries in outstanding command array. For all these stale<br /> I/O entries, eh_abort was issued and aborted (fast_fail_io = 2009h) but<br /> I/Os could not complete while vport delete is in process of deleting.<br /> <br /> BUG: kernel NULL pointer dereference, address: 000000000000001c<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> Workqueue: qla2xxx_wq qla_do_work [qla2xxx]<br /> RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0<br /> RSP: 0018:ffffa1e1e150fc68 EFLAGS: 00010046<br /> RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000001<br /> RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8ce208a7a0d0<br /> RBP: ffff8ce208a7a0d0 R08: 0000000000000000 R09: ffff8ce378aac9c8<br /> R10: ffff8ce378aac8a0 R11: ffffa1e1e150f9d8 R12: 0000000000000000<br /> R13: 0000000000000000 R14: ffff8ce378aac9c8 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff8d217f000000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000000000001c CR3: 0000002089acc000 CR4: 0000000000350ee0<br /> Call Trace:<br /> <br /> qla2xxx_qpair_sp_free_dma+0x417/0x4e0<br /> ? qla2xxx_qpair_sp_compl+0x10d/0x1a0<br /> ? qla2x00_status_entry+0x768/0x2830<br /> ? newidle_balance+0x2f0/0x430<br /> ? dequeue_entity+0x100/0x3c0<br /> ? qla24xx_process_response_queue+0x6a1/0x19e0<br /> ? __schedule+0x2d5/0x1140<br /> ? qla_do_work+0x47/0x60<br /> ? process_one_work+0x267/0x440<br /> ? process_one_work+0x440/0x440<br /> ? worker_thread+0x2d/0x3d0<br /> ? process_one_work+0x440/0x440<br /> ? kthread+0x156/0x180<br /> ? set_kthread_struct+0x50/0x50<br /> ? ret_from_fork+0x22/0x30<br /> <br /> <br /> Send out async logout explicitly for all the ports during vport delete.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/imx-irqsteer: Handle runtime power management correctly<br /> <br /> The power domain is automatically activated from clk_prepare(). However, on<br /> certain platforms like i.MX8QM and i.MX8QXP, the power-on handling invokes<br /> sleeping functions, which triggers the &amp;#39;scheduling while atomic&amp;#39; bug in the<br /> context switch path during device probing:<br /> <br /> BUG: scheduling while atomic: kworker/u13:1/48/0x00000002<br /> Call trace:<br /> __schedule_bug+0x54/0x6c<br /> __schedule+0x7f0/0xa94<br /> schedule+0x5c/0xc4<br /> schedule_preempt_disabled+0x24/0x40<br /> __mutex_lock.constprop.0+0x2c0/0x540<br /> __mutex_lock_slowpath+0x14/0x20<br /> mutex_lock+0x48/0x54<br /> clk_prepare_lock+0x44/0xa0<br /> clk_prepare+0x20/0x44<br /> imx_irqsteer_resume+0x28/0xe0<br /> pm_generic_runtime_resume+0x2c/0x44<br /> __genpd_runtime_resume+0x30/0x80<br /> genpd_runtime_resume+0xc8/0x2c0<br /> __rpm_callback+0x48/0x1d8<br /> rpm_callback+0x6c/0x78<br /> rpm_resume+0x490/0x6b4<br /> __pm_runtime_resume+0x50/0x94<br /> irq_chip_pm_get+0x2c/0xa0<br /> __irq_do_set_handler+0x178/0x24c<br /> irq_set_chained_handler_and_data+0x60/0xa4<br /> mxc_gpio_probe+0x160/0x4b0<br /> <br /> Cure this by implementing the irq_bus_lock/sync_unlock() interrupt chip<br /> callbacks and handle power management in them as they are invoked from<br /> non-atomic context.<br /> <br /> [ tglx: Rewrote change log, added Fixes tag ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Add a per-VF limit on number of FDIR filters<br /> <br /> While the iavf driver adds a s/w limit (128) on the number of FDIR<br /> filters that the VF can request, a malicious VF driver can request more<br /> than that and exhaust the resources for other VFs.<br /> <br /> Add a similar limit in ice.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kobject_uevent: Fix OOB access within zap_modalias_env()<br /> <br /> zap_modalias_env() wrongly calculates size of memory block to move, so<br /> will cause OOB memory access issue if variable MODALIAS is not the last<br /> one within its @env parameter, fixed by correcting size to memmove.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/client: Fix error code in drm_client_buffer_vmap_local()<br /> <br /> This function accidentally returns zero/success on the failure path.<br /> It leads to locking issues and an uninitialized *map_copy in the<br /> caller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: TAS2781: Fix tasdev_load_calibrated_data()<br /> <br /> This function has a reversed if statement so it&amp;#39;s either a no-op or it<br /> leads to a NULL dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: microchip-core: ensure TX and RX FIFOs are empty at start of a transfer<br /> <br /> While transmitting with rx_len == 0, the RX FIFO is not going to be<br /> emptied in the interrupt handler. A subsequent transfer could then<br /> read crap from the previous transfer out of the RX FIFO into the<br /> start RX buffer. The core provides a register that will empty the RX and<br /> TX FIFOs, so do that before each transfer.