Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: f_fs: Fix use-after-free for epfile<br /> <br /> Consider a case where ffs_func_eps_disable is called from<br /> ffs_func_disable as part of composition switch and at the<br /> same time ffs_epfile_release get called from userspace.<br /> ffs_epfile_release will free up the read buffer and call<br /> ffs_data_closed which in turn destroys ffs-&gt;epfiles and<br /> mark it as NULL. While this was happening the driver has<br /> already initialized the local epfile in ffs_func_eps_disable<br /> which is now freed and waiting to acquire the spinlock. Once<br /> spinlock is acquired the driver proceeds with the stale value<br /> of epfile and tries to free the already freed read buffer<br /> causing use-after-free.<br /> <br /> Following is the illustration of the race:<br /> <br /> CPU1 CPU2<br /> <br /> ffs_func_eps_disable<br /> epfiles (local copy)<br /> ffs_epfile_release<br /> ffs_data_closed<br /> if (last file closed)<br /> ffs_data_reset<br /> ffs_data_clear<br /> ffs_epfiles_destroy<br /> spin_lock<br /> dereference epfiles<br /> <br /> Fix this races by taking epfiles local copy &amp; assigning it under<br /> spinlock and if epfiles(local) is null then update it in ffs-&gt;epfiles<br /> then finally destroy it.<br /> Extending the scope further from the race, protecting the ep related<br /> structures, and concurrent accesses.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qedf: Fix refcount issue when LOGO is received during TMF<br /> <br /> Hung task call trace was seen during LOGO processing.<br /> <br /> [ 974.309060] [0000:00:00.0]:[qedf_eh_device_reset:868]: 1:0:2:0: LUN RESET Issued...<br /> [ 974.309065] [0000:00:00.0]:[qedf_initiate_tmf:2422]: tm_flags 0x10 sc_cmd 00000000c16b930f op = 0x2a target_id = 0x2 lun=0<br /> [ 974.309178] [0000:00:00.0]:[qedf_initiate_tmf:2431]: portid=016900 tm_flags =LUN RESET<br /> [ 974.309222] [0000:00:00.0]:[qedf_initiate_tmf:2438]: orig io_req = 00000000ec78df8f xid = 0x180 ref_cnt = 1.<br /> [ 974.309625] host1: rport 016900: Received LOGO request while in state Ready<br /> [ 974.309627] host1: rport 016900: Delete port<br /> [ 974.309642] host1: rport 016900: work event 3<br /> [ 974.309644] host1: rport 016900: lld callback ev 3<br /> [ 974.313243] [0000:61:00.2]:[qedf_execute_tmf:2383]:1: fcport is uploading, not executing flush.<br /> [ 974.313295] [0000:61:00.2]:[qedf_execute_tmf:2400]:1: task mgmt command success...<br /> [ 984.031088] INFO: task jbd2/dm-15-8:7645 blocked for more than 120 seconds.<br /> [ 984.031136] Not tainted 4.18.0-305.el8.x86_64 #1<br /> <br /> [ 984.031166] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> [ 984.031209] jbd2/dm-15-8 D 0 7645 2 0x80004080<br /> [ 984.031212] Call Trace:<br /> [ 984.031222] __schedule+0x2c4/0x700<br /> [ 984.031230] ? unfreeze_partials.isra.83+0x16e/0x1a0<br /> [ 984.031233] ? bit_wait_timeout+0x90/0x90<br /> [ 984.031235] schedule+0x38/0xa0<br /> [ 984.031238] io_schedule+0x12/0x40<br /> [ 984.031240] bit_wait_io+0xd/0x50<br /> [ 984.031243] __wait_on_bit+0x6c/0x80<br /> [ 984.031248] ? free_buffer_head+0x21/0x50<br /> [ 984.031251] out_of_line_wait_on_bit+0x91/0xb0<br /> [ 984.031257] ? init_wait_var_entry+0x50/0x50<br /> [ 984.031268] jbd2_journal_commit_transaction+0x112e/0x19f0 [jbd2]<br /> [ 984.031280] kjournald2+0xbd/0x270 [jbd2]<br /> [ 984.031284] ? finish_wait+0x80/0x80<br /> [ 984.031291] ? commit_timeout+0x10/0x10 [jbd2]<br /> [ 984.031294] kthread+0x116/0x130<br /> [ 984.031300] ? kthread_flush_work_fn+0x10/0x10<br /> [ 984.031305] ret_from_fork+0x1f/0x40<br /> <br /> There was a ref count issue when LOGO is received during TMF. This leads to<br /> one of the I/Os hanging with the driver. Fix the ref count.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: myrs: Fix crash in error case<br /> <br /> In myrs_detect(), cs-&gt;disable_intr is NULL when privdata-&gt;hw_init() fails<br /> with non-zero. In this case, myrs_cleanup(cs) will call a NULL ptr and<br /> crash the kernel.<br /> <br /> [ 1.105606] myrs 0000:00:03.0: Unknown Initialization Error 5A<br /> [ 1.105872] myrs 0000:00:03.0: Failed to initialize Controller<br /> [ 1.106082] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [ 1.110774] Call Trace:<br /> [ 1.110950] myrs_cleanup+0xe4/0x150 [myrs]<br /> [ 1.111135] myrs_probe.cold+0x91/0x56a [myrs]<br /> [ 1.111302] ? DAC960_GEM_intr_handler+0x1f0/0x1f0 [myrs]<br /> [ 1.111500] local_pci_probe+0x48/0x90

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qedf: Add stag_work to all the vports<br /> <br /> Call trace seen when creating NPIV ports, only 32 out of 64 show online.<br /> stag work was not initialized for vport, hence initialize the stag work.<br /> <br /> WARNING: CPU: 8 PID: 645 at kernel/workqueue.c:1635 __queue_delayed_work+0x68/0x80<br /> CPU: 8 PID: 645 Comm: kworker/8:1 Kdump: loaded Tainted: G IOE --------- --<br /> 4.18.0-348.el8.x86_64 #1<br /> Hardware name: Dell Inc. PowerEdge MX740c/0177V9, BIOS 2.12.2 07/09/2021<br /> Workqueue: events fc_lport_timeout [libfc]<br /> RIP: 0010:__queue_delayed_work+0x68/0x80<br /> Code: 89 b2 88 00 00 00 44 89 82 90 00 00 00 48 01 c8 48 89 42 50 41 81<br /> f8 00 20 00 00 75 1d e9 60 24 07 00 44 89 c7 e9 98 f6 ff ff 0b eb<br /> c5 0f 0b eb a1 0f 0b eb a7 0f 0b eb ac 44 89 c6 e9 40 23<br /> RSP: 0018:ffffae514bc3be40 EFLAGS: 00010006<br /> RAX: ffff8d25d6143750 RBX: 0000000000000202 RCX: 0000000000000002<br /> RDX: ffff8d2e31383748 RSI: ffff8d25c000d600 RDI: ffff8d2e31383788<br /> RBP: ffff8d2e31380de0 R08: 0000000000002000 R09: ffff8d2e31383750<br /> R10: ffffffffc0c957e0 R11: ffff8d2624800000 R12: ffff8d2e31380a58<br /> R13: ffff8d2d915eb000 R14: ffff8d25c499b5c0 R15: ffff8d2e31380e18<br /> FS: 0000000000000000(0000) GS:ffff8d2d1fb00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000055fd0484b8b8 CR3: 00000008ffc10006 CR4: 00000000007706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> queue_delayed_work_on+0x36/0x40<br /> qedf_elsct_send+0x57/0x60 [qedf]<br /> fc_lport_enter_flogi+0x90/0xc0 [libfc]<br /> fc_lport_timeout+0xb7/0x140 [libfc]<br /> process_one_work+0x1a7/0x360<br /> ? create_worker+0x1a0/0x1a0<br /> worker_thread+0x30/0x390<br /> ? create_worker+0x1a0/0x1a0<br /> kthread+0x116/0x130<br /> ? kthread_flush_work_fn+0x10/0x10<br /> ret_from_fork+0x35/0x40<br /> ---[ end trace 008f00f722f2c2ff ]--<br /> <br /> Initialize stag work for all the vports.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vc4: Fix deadlock on DSI device attach error<br /> <br /> DSI device attach to DSI host will be done with host device&amp;#39;s lock<br /> held.<br /> <br /> Un-registering host in "device attach" error path (ex: probe retry)<br /> will result in deadlock with below call trace and non operational<br /> DSI display.<br /> <br /> Startup Call trace:<br /> [ 35.043036] rt_mutex_slowlock.constprop.21+0x184/0x1b8<br /> [ 35.043048] mutex_lock_nested+0x7c/0xc8<br /> [ 35.043060] device_del+0x4c/0x3e8<br /> [ 35.043075] device_unregister+0x20/0x40<br /> [ 35.043082] mipi_dsi_remove_device_fn+0x18/0x28<br /> [ 35.043093] device_for_each_child+0x68/0xb0<br /> [ 35.043105] mipi_dsi_host_unregister+0x40/0x90<br /> [ 35.043115] vc4_dsi_host_attach+0xf0/0x120 [vc4]<br /> [ 35.043199] mipi_dsi_attach+0x30/0x48<br /> [ 35.043209] tc358762_probe+0x128/0x164 [tc358762]<br /> [ 35.043225] mipi_dsi_drv_probe+0x28/0x38<br /> [ 35.043234] really_probe+0xc0/0x318<br /> [ 35.043244] __driver_probe_device+0x80/0xe8<br /> [ 35.043254] driver_probe_device+0xb8/0x118<br /> [ 35.043263] __device_attach_driver+0x98/0xe8<br /> [ 35.043273] bus_for_each_drv+0x84/0xd8<br /> [ 35.043281] __device_attach+0xf0/0x150<br /> [ 35.043290] device_initial_probe+0x1c/0x28<br /> [ 35.043300] bus_probe_device+0xa4/0xb0<br /> [ 35.043308] deferred_probe_work_func+0xa0/0xe0<br /> [ 35.043318] process_one_work+0x254/0x700<br /> [ 35.043330] worker_thread+0x4c/0x448<br /> [ 35.043339] kthread+0x19c/0x1a8<br /> [ 35.043348] ret_from_fork+0x10/0x20<br /> <br /> Shutdown Call trace:<br /> [ 365.565417] Call trace:<br /> [ 365.565423] __switch_to+0x148/0x200<br /> [ 365.565452] __schedule+0x340/0x9c8<br /> [ 365.565467] schedule+0x48/0x110<br /> [ 365.565479] schedule_timeout+0x3b0/0x448<br /> [ 365.565496] wait_for_completion+0xac/0x138<br /> [ 365.565509] __flush_work+0x218/0x4e0<br /> [ 365.565523] flush_work+0x1c/0x28<br /> [ 365.565536] wait_for_device_probe+0x68/0x158<br /> [ 365.565550] device_shutdown+0x24/0x348<br /> [ 365.565561] kernel_restart_prepare+0x40/0x50<br /> [ 365.565578] kernel_restart+0x20/0x70<br /> [ 365.565591] __do_sys_reboot+0x10c/0x220<br /> [ 365.565605] __arm64_sys_reboot+0x2c/0x38<br /> [ 365.565619] invoke_syscall+0x4c/0x110<br /> [ 365.565634] el0_svc_common.constprop.3+0xfc/0x120<br /> [ 365.565648] do_el0_svc+0x2c/0x90<br /> [ 365.565661] el0_svc+0x4c/0xf0<br /> [ 365.565671] el0t_64_sync_handler+0x90/0xb8<br /> [ 365.565682] el0t_64_sync+0x180/0x184

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Fix the behavior of READ near OFFSET_MAX<br /> <br /> Dan Aloni reports:<br /> &gt; Due to commit 8cfb9015280d ("NFS: Always provide aligned buffers to<br /> &gt; the RPC read layers") on the client, a read of 0xfff is aligned up<br /> &gt; to server rsize of 0x1000.<br /> &gt;<br /> &gt; As a result, in a test where the server has a file of size<br /> &gt; 0x7fffffffffffffff, and the client tries to read from the offset<br /> &gt; 0x7ffffffffffff000, the read causes loff_t overflow in the server<br /> &gt; and it returns an NFS code of EINVAL to the client. The client as<br /> &gt; a result indefinitely retries the request.<br /> <br /> The Linux NFS client does not handle NFS?ERR_INVAL, even though all<br /> NFS specifications permit servers to return that status code for a<br /> READ.<br /> <br /> Instead of NFS?ERR_INVAL, have out-of-range READ requests succeed<br /> and return a short result. Set the EOF flag in the result to prevent<br /> the client from retrying the READ request. This behavior appears to<br /> be consistent with Solaris NFS servers.<br /> <br /> Note that NFSv3 and NFSv4 use u64 offset values on the wire. These<br /> must be converted to loff_t internally before use -- an implicit<br /> type cast is not adequate for this purpose. Otherwise VFS checks<br /> against sb-&gt;s_maxbytes do not work properly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Fix ia_size underflow<br /> <br /> iattr::ia_size is a loff_t, which is a signed 64-bit type. NFSv3 and<br /> NFSv4 both define file size as an unsigned 64-bit type. Thus there<br /> is a range of valid file size values an NFS client can send that is<br /> already larger than Linux can handle.<br /> <br /> Currently decode_fattr4() dumps a full u64 value into ia_size. If<br /> that value happens to be larger than S64_MAX, then ia_size<br /> underflows. I&amp;#39;m about to fix up the NFSv3 behavior as well, so let&amp;#39;s<br /> catch the underflow in the common code path: nfsd_setattr().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Fix NFSv3 SETATTR/CREATE&amp;#39;s handling of large file sizes<br /> <br /> iattr::ia_size is a loff_t, so these NFSv3 procedures must be<br /> careful to deal with incoming client size values that are larger<br /> than s64_max without corrupting the value.<br /> <br /> Silently capping the value results in storing a different value<br /> than the client passed in which is unexpected behavior, so remove<br /> the min_t() check in decode_sattr3().<br /> <br /> Note that RFC 1813 permits only the WRITE procedure to return<br /> NFS3ERR_FBIG. We believe that NFSv3 reference implementations<br /> also return NFS3ERR_FBIG when ia_size is too large.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: isotp: fix potential CAN frame reception race in isotp_rcv()<br /> <br /> When receiving a CAN frame the current code logic does not consider<br /> concurrently receiving processes which do not show up in real world<br /> usage.<br /> <br /> Ziyang Xuan writes:<br /> <br /> The following syz problem is one of the scenarios. so-&gt;rx.len is<br /> changed by isotp_rcv_ff() during isotp_rcv_cf(), so-&gt;rx.len equals<br /> 0 before alloc_skb() and equals 4096 after alloc_skb(). That will<br /> trigger skb_over_panic() in skb_put().<br /> <br /> =======================================================<br /> CPU: 1 PID: 19 Comm: ksoftirqd/1 Not tainted 5.16.0-rc8-syzkaller #0<br /> RIP: 0010:skb_panic+0x16c/0x16e net/core/skbuff.c:113<br /> Call Trace:<br /> <br /> skb_over_panic net/core/skbuff.c:118 [inline]<br /> skb_put.cold+0x24/0x24 net/core/skbuff.c:1990<br /> isotp_rcv_cf net/can/isotp.c:570 [inline]<br /> isotp_rcv+0xa38/0x1e30 net/can/isotp.c:668<br /> deliver net/can/af_can.c:574 [inline]<br /> can_rcv_filter+0x445/0x8d0 net/can/af_can.c:635<br /> can_receive+0x31d/0x580 net/can/af_can.c:665<br /> can_rcv+0x120/0x1c0 net/can/af_can.c:696<br /> __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5465<br /> __netif_receive_skb+0x24/0x1b0 net/core/dev.c:5579<br /> <br /> Therefore we make sure the state changes and data structures stay<br /> consistent at CAN frame reception time by adding a spin_lock in<br /> isotp_rcv(). This fixes the issue reported by syzkaller but does not<br /> affect real world operation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ima: fix reference leak in asymmetric_verify()<br /> <br /> Don&amp;#39;t leak a reference to the key if its algorithm is unknown.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> audit: don&amp;#39;t deref the syscall args when checking the openat2 open_how::flags<br /> <br /> As reported by Jeff, dereferencing the openat2 syscall argument in<br /> audit_match_perm() to obtain the open_how::flags can result in an<br /> oops/page-fault. This patch fixes this by using the open_how struct<br /> that we store in the audit_context with audit_openat2_how().<br /> <br /> Independent of this patch, Richard Guy Briggs posted a similar patch<br /> to the audit mailing list roughly 40 minutes after this patch was<br /> posted.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix KASAN error in LAG NETDEV_UNREGISTER handler<br /> <br /> Currently, the same handler is called for both a NETDEV_BONDING_INFO<br /> LAG unlink notification as for a NETDEV_UNREGISTER call. This is<br /> causing a problem though, since the netdev_notifier_info passed has<br /> a different structure depending on which event is passed. The problem<br /> manifests as a call trace from a BUG: KASAN stack-out-of-bounds error.<br /> <br /> Fix this by creating a handler specific to NETDEV_UNREGISTER that only<br /> is passed valid elements in the netdev_notifier_info struct for the<br /> NETDEV_UNREGISTER event.<br /> <br /> Also included is the removal of an unbalanced dev_put on the peer_netdev<br /> and related braces.