Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: mcast: use rcu-safe version of ipv6_get_lladdr()<br /> <br /> Some time ago 8965779d2c0e ("ipv6,mcast: always hold idev-&gt;lock before mca_lock")<br /> switched ipv6_get_lladdr() to __ipv6_get_lladdr(), which is rcu-unsafe<br /> version. That was OK, because idev-&gt;lock was held for these codepaths.<br /> <br /> In 88e2ca308094 ("mld: convert ifmcaddr6 to RCU") these external locks were<br /> removed, so we probably need to restore the original rcu-safe call.<br /> <br /> Otherwise, we occasionally get a machine crashed/stalled with the following<br /> in dmesg:<br /> <br /> [ 3405.966610][T230589] general protection fault, probably for non-canonical address 0xdead00000000008c: 0000 [#1] SMP NOPTI<br /> [ 3405.982083][T230589] CPU: 44 PID: 230589 Comm: kworker/44:3 Tainted: G O 5.15.19-cloudflare-2022.2.1 #1<br /> [ 3405.998061][T230589] Hardware name: SUPA-COOL-SERV<br /> [ 3406.009552][T230589] Workqueue: mld mld_ifc_work<br /> [ 3406.017224][T230589] RIP: 0010:__ipv6_get_lladdr+0x34/0x60<br /> [ 3406.025780][T230589] Code: 57 10 48 83 c7 08 48 89 e5 48 39 d7 74 3e 48 8d 82 38 ff ff ff eb 13 48 8b 90 d0 00 00 00 48 8d 82 38 ff ff ff 48 39 d7 74 22 83 78 32 20 77 1b 75 e4 89 ca 23 50 2c 75 dd 48 8b 50 08 48 8b<br /> [ 3406.055748][T230589] RSP: 0018:ffff94e4b3fc3d10 EFLAGS: 00010202<br /> [ 3406.065617][T230589] RAX: dead00000000005a RBX: ffff94e4b3fc3d30 RCX: 0000000000000040<br /> [ 3406.077477][T230589] RDX: dead000000000122 RSI: ffff94e4b3fc3d30 RDI: ffff8c3a31431008<br /> [ 3406.089389][T230589] RBP: ffff94e4b3fc3d10 R08: 0000000000000000 R09: 0000000000000000<br /> [ 3406.101445][T230589] R10: ffff8c3a31430000 R11: 000000000000000b R12: ffff8c2c37887100<br /> [ 3406.113553][T230589] R13: ffff8c3a39537000 R14: 00000000000005dc R15: ffff8c3a31431000<br /> [ 3406.125730][T230589] FS: 0000000000000000(0000) GS:ffff8c3b9fc80000(0000) knlGS:0000000000000000<br /> [ 3406.138992][T230589] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 3406.149895][T230589] CR2: 00007f0dfea1db60 CR3: 000000387b5f2000 CR4: 0000000000350ee0<br /> [ 3406.162421][T230589] Call Trace:<br /> [ 3406.170235][T230589] <br /> [ 3406.177736][T230589] mld_newpack+0xfe/0x1a0<br /> [ 3406.186686][T230589] add_grhead+0x87/0xa0<br /> [ 3406.195498][T230589] add_grec+0x485/0x4e0<br /> [ 3406.204310][T230589] ? newidle_balance+0x126/0x3f0<br /> [ 3406.214024][T230589] mld_ifc_work+0x15d/0x450<br /> [ 3406.223279][T230589] process_one_work+0x1e6/0x380<br /> [ 3406.232982][T230589] worker_thread+0x50/0x3a0<br /> [ 3406.242371][T230589] ? rescuer_thread+0x360/0x360<br /> [ 3406.252175][T230589] kthread+0x127/0x150<br /> [ 3406.261197][T230589] ? set_kthread_struct+0x40/0x40<br /> [ 3406.271287][T230589] ret_from_fork+0x22/0x30<br /> [ 3406.280812][T230589] <br /> [ 3406.288937][T230589] Modules linked in: ... [last unloaded: kheaders]<br /> [ 3406.476714][T230589] ---[ end trace 3525a7655f2f3b9e ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock: remove vsock from connected table when connect is interrupted by a signal<br /> <br /> vsock_connect() expects that the socket could already be in the<br /> TCP_ESTABLISHED state when the connecting task wakes up with a signal<br /> pending. If this happens the socket will be in the connected table, and<br /> it is not removed when the socket state is reset. In this situation it&amp;#39;s<br /> common for the process to retry connect(), and if the connection is<br /> successful the socket will be added to the connected table a second<br /> time, corrupting the list.<br /> <br /> Prevent this by calling vsock_remove_connected() if a signal is received<br /> while waiting for a connection. This is harmless if the socket is not in<br /> the connected table, and if it is in the table then removing it will<br /> prevent list corruption from a double add.<br /> <br /> Note for backporting: this patch requires d5afa82c977e ("vsock: correct<br /> removal of socket from the list"), which is in all current stable trees<br /> except 4.9.y.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iwlwifi: fix use-after-free<br /> <br /> If no firmware was present at all (or, presumably, all of the<br /> firmware files failed to parse), we end up unbinding by calling<br /> device_release_driver(), which calls remove(), which then in<br /> iwlwifi calls iwl_drv_stop(), freeing the &amp;#39;drv&amp;#39; struct. However<br /> the new code I added will still erroneously access it after it<br /> was freed.<br /> <br /> Set &amp;#39;failure=false&amp;#39; in this case to avoid the access, all data<br /> was already freed anyway.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-rdma: fix possible use-after-free in transport error_recovery work<br /> <br /> While nvme_rdma_submit_async_event_work is checking the ctrl and queue<br /> state before preparing the AER command and scheduling io_work, in order<br /> to fully prevent a race where this check is not reliable the error<br /> recovery work must flush async_event_work before continuing to destroy<br /> the admin queue after setting the ctrl state to RESETTING such that<br /> there is no race .submit_async_event and the error recovery handler<br /> itself changing the ctrl state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-tcp: fix possible use-after-free in transport error_recovery work<br /> <br /> While nvme_tcp_submit_async_event_work is checking the ctrl and queue<br /> state before preparing the AER command and scheduling io_work, in order<br /> to fully prevent a race where this check is not reliable the error<br /> recovery work must flush async_event_work before continuing to destroy<br /> the admin queue after setting the ctrl state to RESETTING such that<br /> there is no race .submit_async_event and the error recovery handler<br /> itself changing the ctrl state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme: fix a possible use-after-free in controller reset during load<br /> <br /> Unlike .queue_rq, in .submit_async_event drivers may not check the ctrl<br /> readiness for AER submission. This may lead to a use-after-free<br /> condition that was observed with nvme-tcp.<br /> <br /> The race condition may happen in the following scenario:<br /> 1. driver executes its reset_ctrl_work<br /> 2. -&gt; nvme_stop_ctrl - flushes ctrl async_event_work<br /> 3. ctrl sends AEN which is received by the host, which in turn<br /> schedules AEN handling<br /> 4. teardown admin queue (which releases the queue socket)<br /> 5. AEN processed, submits another AER, calling the driver to submit<br /> 6. driver attempts to send the cmd<br /> ==&gt; use-after-free<br /> <br /> In order to fix that, add ctrl state check to validate the ctrl<br /> is actually able to accept the AER submission.<br /> <br /> This addresses the above race in controller resets because the driver<br /> during teardown should:<br /> 1. change ctrl state to RESETTING<br /> 2. flush async_event_work (as well as other async work elements)<br /> <br /> So after 1,2, any other AER command will find the<br /> ctrl state to be RESETTING and bail out without submitting the AER.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: pm8001: Fix use-after-free for aborted TMF sas_task<br /> <br /> Currently a use-after-free may occur if a TMF sas_task is aborted before we<br /> handle the IO completion in mpi_ssp_completion(). The abort occurs due to<br /> timeout.<br /> <br /> When the timeout occurs, the SAS_TASK_STATE_ABORTED flag is set and the<br /> sas_task is freed in pm8001_exec_internal_tmf_task().<br /> <br /> However, if the I/O completion occurs later, the I/O completion still<br /> thinks that the sas_task is available. Fix this by clearing the ccb-&gt;task<br /> if the TMF times out - the I/O completion handler does nothing if this<br /> pointer is cleared.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: pm8001: Fix use-after-free for aborted SSP/STP sas_task<br /> <br /> Currently a use-after-free may occur if a sas_task is aborted by the upper<br /> layer before we handle the I/O completion in mpi_ssp_completion() or<br /> mpi_sata_completion().<br /> <br /> In this case, the following are the two steps in handling those I/O<br /> completions:<br /> <br /> - Call complete() to inform the upper layer handler of completion of<br /> the I/O.<br /> <br /> - Release driver resources associated with the sas_task in<br /> pm8001_ccb_task_free() call.<br /> <br /> When complete() is called, the upper layer may free the sas_task. As such,<br /> we should not touch the associated sas_task afterwards, but we do so in the<br /> pm8001_ccb_task_free() call.<br /> <br /> Fix by swapping the complete() and pm8001_ccb_task_free() calls ordering.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: parsers: qcom: Fix kernel panic on skipped partition<br /> <br /> In the event of a skipped partition (case when the entry name is empty)<br /> the kernel panics in the cleanup function as the name entry is NULL.<br /> Rework the parser logic by first checking the real partition number and<br /> then allocate the space and set the data for the valid partitions.<br /> <br /> The logic was also fundamentally wrong as with a skipped partition, the<br /> parts number returned was incorrect by not decreasing it for the skipped<br /> partitions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: Fix a deadlock in the error handler<br /> <br /> The following deadlock has been observed on a test setup:<br /> <br /> - All tags allocated<br /> <br /> - The SCSI error handler calls ufshcd_eh_host_reset_handler()<br /> <br /> - ufshcd_eh_host_reset_handler() queues work that calls<br /> ufshcd_err_handler()<br /> <br /> - ufshcd_err_handler() locks up as follows:<br /> <br /> Workqueue: ufs_eh_wq_0 ufshcd_err_handler.cfi_jt<br /> Call trace:<br /> __switch_to+0x298/0x5d8<br /> __schedule+0x6cc/0xa94<br /> schedule+0x12c/0x298<br /> blk_mq_get_tag+0x210/0x480<br /> __blk_mq_alloc_request+0x1c8/0x284<br /> blk_get_request+0x74/0x134<br /> ufshcd_exec_dev_cmd+0x68/0x640<br /> ufshcd_verify_dev_init+0x68/0x35c<br /> ufshcd_probe_hba+0x12c/0x1cb8<br /> ufshcd_host_reset_and_restore+0x88/0x254<br /> ufshcd_reset_and_restore+0xd0/0x354<br /> ufshcd_err_handler+0x408/0xc58<br /> process_one_work+0x24c/0x66c<br /> worker_thread+0x3e8/0xa4c<br /> kthread+0x150/0x1b4<br /> ret_from_fork+0x10/0x30<br /> <br /> Fix this lockup by making ufshcd_exec_dev_cmd() allocate a reserved<br /> request.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/fixmap: Fix VM debug warning on unmap<br /> <br /> Unmapping a fixmap entry is done by calling __set_fixmap()<br /> with FIXMAP_PAGE_CLEAR as flags.<br /> <br /> Today, powerpc __set_fixmap() calls map_kernel_page().<br /> <br /> map_kernel_page() is not happy when called a second time<br /> for the same page.<br /> <br /> WARNING: CPU: 0 PID: 1 at arch/powerpc/mm/pgtable.c:194 set_pte_at+0xc/0x1e8<br /> CPU: 0 PID: 1 Comm: swapper Not tainted 5.16.0-rc3-s3k-dev-01993-g350ff07feb7d-dirty #682<br /> NIP: c0017cd4 LR: c00187f0 CTR: 00000010<br /> REGS: e1011d50 TRAP: 0700 Not tainted (5.16.0-rc3-s3k-dev-01993-g350ff07feb7d-dirty)<br /> MSR: 00029032 CR: 42000208 XER: 00000000<br /> <br /> GPR00: c0165fec e1011e10 c14c0000 c0ee2550 ff800000 c0f3d000 00000000 c001686c<br /> GPR08: 00001000 b00045a9 00000001 c0f58460 c0f50000 00000000 c0007e10 00000000<br /> GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000<br /> GPR24: 00000000 00000000 c0ee2550 00000000 c0f57000 00000ff8 00000000 ff800000<br /> NIP [c0017cd4] set_pte_at+0xc/0x1e8<br /> LR [c00187f0] map_kernel_page+0x9c/0x100<br /> Call Trace:<br /> [e1011e10] [c0736c68] vsnprintf+0x358/0x6c8 (unreliable)<br /> [e1011e30] [c0165fec] __set_fixmap+0x30/0x44<br /> [e1011e40] [c0c13bdc] early_iounmap+0x11c/0x170<br /> [e1011e70] [c0c06cb0] ioremap_legacy_serial_console+0x88/0xc0<br /> [e1011e90] [c0c03634] do_one_initcall+0x80/0x178<br /> [e1011ef0] [c0c0385c] kernel_init_freeable+0xb4/0x250<br /> [e1011f20] [c0007e34] kernel_init+0x24/0x140<br /> [e1011f30] [c0016268] ret_from_kernel_thread+0x5c/0x64<br /> Instruction dump:<br /> 7fe3fb78 48019689 80010014 7c630034 83e1000c 5463d97e 7c0803a6 38210010<br /> 4e800020 81250000 712a0001 41820008 9421ffe0 93e1001c 48000030<br /> <br /> Implement unmap_kernel_page() which clears an existing pte.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sunrpc: fix reference count leaks in rpc_sysfs_xprt_state_change<br /> <br /> The refcount leak issues take place in an error handling path. When the<br /> 3rd argument buf doesn&amp;#39;t match with "offline", "online" or "remove", the<br /> function simply returns -EINVAL and forgets to decrease the reference<br /> count of a rpc_xprt object and a rpc_xprt_switch object increased by<br /> rpc_sysfs_xprt_kobj_get_xprt() and<br /> rpc_sysfs_xprt_kobj_get_xprt_switch(), causing reference count leaks of<br /> both unused objects.<br /> <br /> Fix this issue by jumping to the error handling path labelled with<br /> out_put when buf matches none of "offline", "online" or "remove".