Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: cdns3: fix memory double free when handle zero packet<br /> <br /> 829 if (request-&gt;complete) {<br /> 830 spin_unlock(&amp;priv_dev-&gt;lock);<br /> 831 usb_gadget_giveback_request(&amp;priv_ep-&gt;endpoint,<br /> 832 request);<br /> 833 spin_lock(&amp;priv_dev-&gt;lock);<br /> 834 }<br /> 835<br /> 836 if (request-&gt;buf == priv_dev-&gt;zlp_buf)<br /> 837 cdns3_gadget_ep_free_request(&amp;priv_ep-&gt;endpoint, request);<br /> <br /> Driver append an additional zero packet request when queue a packet, which<br /> length mod max packet size is 0. When transfer complete, run to line 831,<br /> usb_gadget_giveback_request() will free this requestion. 836 condition is<br /> true, so cdns3_gadget_ep_free_request() free this request again.<br /> <br /> Log:<br /> <br /> [ 1920.140696][ T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3]<br /> [ 1920.140696][ T150]<br /> [ 1920.151837][ T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36):<br /> [ 1920.159082][ T150] cdns3_gadget_giveback+0x134/0x2c0 [cdns3]<br /> [ 1920.164988][ T150] cdns3_transfer_completed+0x438/0x5f8 [cdns3]<br /> <br /> Add check at line 829, skip call usb_gadget_giveback_request() if it is<br /> additional zero length packet request. Needn&amp;#39;t call<br /> usb_gadget_giveback_request() because it is allocated in this driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: cdns3: fixed memory use after free at cdns3_gadget_ep_disable()<br /> <br /> ...<br /> cdns3_gadget_ep_free_request(&amp;priv_ep-&gt;endpoint, &amp;priv_req-&gt;request);<br /> list_del_init(&amp;priv_req-&gt;list);<br /> ...<br /> <br /> &amp;#39;priv_req&amp;#39; actually free at cdns3_gadget_ep_free_request(). But<br /> list_del_init() use priv_req-&gt;list after it.<br /> <br /> [ 1542.642868][ T534] BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xd4<br /> [ 1542.642868][ T534]<br /> [ 1542.653162][ T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3):<br /> [ 1542.660311][ T534] __list_del_entry_valid+0x10/0xd4<br /> [ 1542.665375][ T534] cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3]<br /> [ 1542.671571][ T534] usb_ep_disable+0x44/0xe4<br /> [ 1542.675948][ T534] ffs_func_eps_disable+0x64/0xc8<br /> [ 1542.680839][ T534] ffs_func_set_alt+0x74/0x368<br /> [ 1542.685478][ T534] ffs_func_disable+0x18/0x28<br /> <br /> Move list_del_init() before cdns3_gadget_ep_free_request() to resolve this<br /> problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: ep93xx: Add terminator to gpiod_lookup_table<br /> <br /> Without the terminator, if a con_id is passed to gpio_find() that<br /> does not exist in the lookup table the function will not stop looping<br /> correctly, and eventually cause an oops.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> l2tp: pass correct message length to ip6_append_data<br /> <br /> l2tp_ip6_sendmsg needs to avoid accounting for the transport header<br /> twice when splicing more data into an already partially-occupied skbuff.<br /> <br /> To manage this, we check whether the skbuff contains data using<br /> skb_queue_empty when deciding how much data to append using<br /> ip6_append_data.<br /> <br /> However, the code which performed the calculation was incorrect:<br /> <br /> ulen = len + skb_queue_empty(&amp;sk-&gt;sk_write_queue) ? transhdrlen : 0;<br /> <br /> ...due to C operator precedence, this ends up setting ulen to<br /> transhdrlen for messages with a non-zero length, which results in<br /> corrupted packets on the wire.<br /> <br /> Add parentheses to correct the calculation in line with the original<br /> intent.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: virtio/akcipher - Fix stack overflow on memcpy<br /> <br /> sizeof(struct virtio_crypto_akcipher_session_para) is less than<br /> sizeof(struct virtio_crypto_op_ctrl_req::u), copying more bytes from<br /> stack variable leads stack overflow. Clang reports this issue by<br /> commands:<br /> make -j CC=clang-14 mrproper &gt;/dev/null 2&gt;&amp;1<br /> make -j O=/tmp/crypto-build CC=clang-14 allmodconfig &gt;/dev/null 2&gt;&amp;1<br /> make -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/<br /> virtio_crypto_akcipher_algs.o

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_mirred: don&amp;#39;t override retval if we already lost the skb<br /> <br /> If we&amp;#39;re redirecting the skb, and haven&amp;#39;t called tcf_mirred_forward(),<br /> yet, we need to tell the core to drop the skb by setting the retcode<br /> to SHOT. If we have called tcf_mirred_forward(), however, the skb<br /> is out of our hands and returning SHOT will lead to UaF.<br /> <br /> Move the retval override to the error path which actually need it.

A vulnerability in the web-based management interface of Cisco Identity Services Engine (ISE) could allow an unauthenticated, remote attacker to conduct a cross-site request forgery (CSRF) attack and perform arbitrary actions on an affected device.<br /> <br /> This vulnerability is due to insufficient CSRF protections for the web-based management interface of an affected device. An attacker could exploit this vulnerability by persuading a user of the interface to follow a crafted link. A successful exploit could allow the attacker to perform arbitrary actions on the affected device with the privileges of the targeted user.

The HCL BigFix Inventory server is vulnerable to path traversal which enables an attacker to read internal application files from the Inventory server. The BigFix Inventory server does not properly restrict the served static file.<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: fix null-pointer dereference on edid reading<br /> <br /> Use i2c adapter when there isn&amp;#39;t aux_mode in dc_link to fix a<br /> null-pointer derefence that happens when running<br /> igt@kms_force_connector_basic in a system with DCN2.1 and HDMI connector<br /> detected as below:<br /> <br /> [ +0.178146] BUG: kernel NULL pointer dereference, address: 00000000000004c0<br /> [ +0.000010] #PF: supervisor read access in kernel mode<br /> [ +0.000005] #PF: error_code(0x0000) - not-present page<br /> [ +0.000004] PGD 0 P4D 0<br /> [ +0.000006] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ +0.000006] CPU: 15 PID: 2368 Comm: kms_force_conne Not tainted 6.5.0-asdn+ #152<br /> [ +0.000005] Hardware name: HP HP ENVY x360 Convertible 13-ay1xxx/8929, BIOS F.01 07/14/2021<br /> [ +0.000004] RIP: 0010:i2c_transfer+0xd/0x100<br /> [ +0.000011] Code: ea fc ff ff 66 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 55 53 8b 47 10 48 89 fb 48 83 38 00 0f 84 b3 00 00 00 83 3d 2f 80 16<br /> [ +0.000004] RSP: 0018:ffff9c4f89c0fad0 EFLAGS: 00010246<br /> [ +0.000005] RAX: 0000000000000000 RBX: 0000000000000005 RCX: 0000000000000080<br /> [ +0.000003] RDX: 0000000000000002 RSI: ffff9c4f89c0fb20 RDI: 00000000000004b0<br /> [ +0.000003] RBP: ffff9c4f89c0fb80 R08: 0000000000000080 R09: ffff8d8e0b15b980<br /> [ +0.000003] R10: 00000000000380e0 R11: 0000000000000000 R12: 0000000000000080<br /> [ +0.000002] R13: 0000000000000002 R14: ffff9c4f89c0fb0e R15: ffff9c4f89c0fb0f<br /> [ +0.000004] FS: 00007f9ad2176c40(0000) GS:ffff8d90fe9c0000(0000) knlGS:0000000000000000<br /> [ +0.000003] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ +0.000004] CR2: 00000000000004c0 CR3: 0000000121bc4000 CR4: 0000000000750ee0<br /> [ +0.000003] PKRU: 55555554<br /> [ +0.000003] Call Trace:<br /> [ +0.000006] <br /> [ +0.000006] ? __die+0x23/0x70<br /> [ +0.000011] ? page_fault_oops+0x17d/0x4c0<br /> [ +0.000008] ? preempt_count_add+0x6e/0xa0<br /> [ +0.000008] ? srso_alias_return_thunk+0x5/0x7f<br /> [ +0.000011] ? exc_page_fault+0x7f/0x180<br /> [ +0.000009] ? asm_exc_page_fault+0x26/0x30<br /> [ +0.000013] ? i2c_transfer+0xd/0x100<br /> [ +0.000010] drm_do_probe_ddc_edid+0xc2/0x140 [drm]<br /> [ +0.000067] ? srso_alias_return_thunk+0x5/0x7f<br /> [ +0.000006] ? _drm_do_get_edid+0x97/0x3c0 [drm]<br /> [ +0.000043] ? __pfx_drm_do_probe_ddc_edid+0x10/0x10 [drm]<br /> [ +0.000042] edid_block_read+0x3b/0xd0 [drm]<br /> [ +0.000043] _drm_do_get_edid+0xb6/0x3c0 [drm]<br /> [ +0.000041] ? __pfx_drm_do_probe_ddc_edid+0x10/0x10 [drm]<br /> [ +0.000043] drm_edid_read_custom+0x37/0xd0 [drm]<br /> [ +0.000044] amdgpu_dm_connector_mode_valid+0x129/0x1d0 [amdgpu]<br /> [ +0.000153] drm_connector_mode_valid+0x3b/0x60 [drm_kms_helper]<br /> [ +0.000000] __drm_helper_update_and_validate+0xfe/0x3c0 [drm_kms_helper]<br /> [ +0.000000] ? amdgpu_dm_connector_get_modes+0xb6/0x520 [amdgpu]<br /> [ +0.000000] ? srso_alias_return_thunk+0x5/0x7f<br /> [ +0.000000] drm_helper_probe_single_connector_modes+0x2ab/0x540 [drm_kms_helper]<br /> [ +0.000000] status_store+0xb2/0x1f0 [drm]<br /> [ +0.000000] kernfs_fop_write_iter+0x136/0x1d0<br /> [ +0.000000] vfs_write+0x24d/0x440<br /> [ +0.000000] ksys_write+0x6f/0xf0<br /> [ +0.000000] do_syscall_64+0x60/0xc0<br /> [ +0.000000] ? srso_alias_return_thunk+0x5/0x7f<br /> [ +0.000000] ? syscall_exit_to_user_mode+0x2b/0x40<br /> [ +0.000000] ? srso_alias_return_thunk+0x5/0x7f<br /> [ +0.000000] ? do_syscall_64+0x6c/0xc0<br /> [ +0.000000] ? do_syscall_64+0x6c/0xc0<br /> [ +0.000000] entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> [ +0.000000] RIP: 0033:0x7f9ad46b4b00<br /> [ +0.000000] Code: 40 00 48 8b 15 19 b3 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 80 3d e1 3a 0e 00 00 74 17 b8 01 00 00 00 0f 05 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 48 89<br /> [ +0.000000] RSP: 002b:00007ffcbd3bd6d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001<br /> [ +0.000000] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f9ad46b4b00<br /> [ +0.000000] RDX: 0000000000000002 RSI: 00007f9ad48a7417 RDI: 0000000000000009<br /> [ +0.000000] RBP: 0000000000000002 R08<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix potential null pointer dereference in dc_dmub_srv<br /> <br /> Fixes potential null pointer dereference warnings in the<br /> dc_dmub_srv_cmd_list_queue_execute() and dc_dmub_srv_is_hw_pwr_up()<br /> functions.<br /> <br /> In both functions, the &amp;#39;dc_dmub_srv&amp;#39; variable was being dereferenced<br /> before it was checked for null. This could lead to a null pointer<br /> dereference if &amp;#39;dc_dmub_srv&amp;#39; is null. The fix is to check if<br /> &amp;#39;dc_dmub_srv&amp;#39; is null before dereferencing it.<br /> <br /> Thus moving the null checks for &amp;#39;dc_dmub_srv&amp;#39; to the beginning of the<br /> functions to ensure that &amp;#39;dc_dmub_srv&amp;#39; is not null when it is<br /> dereferenced.<br /> <br /> Found by smatch &amp; thus fixing the below:<br /> drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:133 dc_dmub_srv_cmd_list_queue_execute() warn: variable dereferenced before check &amp;#39;dc_dmub_srv&amp;#39; (see line 128)<br /> drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:1167 dc_dmub_srv_is_hw_pwr_up() warn: variable dereferenced before check &amp;#39;dc_dmub_srv&amp;#39; (see line 1164)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (nct6775) Fix access to temperature configuration registers<br /> <br /> The number of temperature configuration registers does<br /> not always match the total number of temperature registers.<br /> This can result in access errors reported if KASAN is enabled.<br /> <br /> BUG: KASAN: global-out-of-bounds in nct6775_probe+0x5654/0x6fe9 nct6775_core

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Fix NULL pointer dereference in sk_psock_verdict_data_ready()<br /> <br /> syzbot reported the following NULL pointer dereference issue [1]:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [...]<br /> RIP: 0010:0x0<br /> [...]<br /> Call Trace:<br /> <br /> sk_psock_verdict_data_ready+0x232/0x340 net/core/skmsg.c:1230<br /> unix_stream_sendmsg+0x9b4/0x1230 net/unix/af_unix.c:2293<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg+0x221/0x270 net/socket.c:745<br /> ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584<br /> ___sys_sendmsg net/socket.c:2638 [inline]<br /> __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667<br /> do_syscall_64+0xf9/0x240<br /> entry_SYSCALL_64_after_hwframe+0x6f/0x77<br /> <br /> If sk_psock_verdict_data_ready() and sk_psock_stop_verdict() are called<br /> concurrently, psock-&gt;saved_data_ready can be NULL, causing the above issue.<br /> <br /> This patch fixes this issue by calling the appropriate data ready function<br /> using the sk_psock_data_ready() helper and protecting it from concurrency<br /> with sk-&gt;sk_callback_lock.