Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/sva: invalidate stale IOTLB entries for kernel address space<br /> <br /> Introduce a new IOMMU interface to flush IOTLB paging cache entries for<br /> the CPU kernel address space. This interface is invoked from the x86<br /> architecture code that manages combined user and kernel page tables,<br /> specifically before any kernel page table page is freed and reused.<br /> <br /> This addresses the main issue with vfree() which is a common occurrence<br /> and can be triggered by unprivileged users. While this resolves the<br /> primary problem, it doesn&amp;#39;t address some extremely rare case related to<br /> memory unplug of memory that was present as reserved memory at boot, which<br /> cannot be triggered by unprivileged users. The discussion can be found at<br /> the link below.<br /> <br /> Enable SVA on x86 architecture since the IOMMU can now receive<br /> notification to flush the paging cache before freeing the CPU kernel page<br /> table pages.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: Set __nocfi on swsusp_arch_resume()<br /> <br /> A DABT is reported[1] on an android based system when resume from hiberate.<br /> This happens because swsusp_arch_suspend_exit() is marked with SYM_CODE_*()<br /> and does not have a CFI hash, but swsusp_arch_resume() will attempt to<br /> verify the CFI hash when calling a copy of swsusp_arch_suspend_exit().<br /> <br /> Given that there&amp;#39;s an existing requirement that the entrypoint to<br /> swsusp_arch_suspend_exit() is the first byte of the .hibernate_exit.text<br /> section, we cannot fix this by marking swsusp_arch_suspend_exit() with<br /> SYM_FUNC_*(). The simplest fix for now is to disable the CFI check in<br /> swsusp_arch_resume().<br /> <br /> Mark swsusp_arch_resume() as __nocfi to disable the CFI check.<br /> <br /> [1]<br /> [ 22.991934][ T1] Unable to handle kernel paging request at virtual address 0000000109170ffc<br /> [ 22.991934][ T1] Mem abort info:<br /> [ 22.991934][ T1] ESR = 0x0000000096000007<br /> [ 22.991934][ T1] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 22.991934][ T1] SET = 0, FnV = 0<br /> [ 22.991934][ T1] EA = 0, S1PTW = 0<br /> [ 22.991934][ T1] FSC = 0x07: level 3 translation fault<br /> [ 22.991934][ T1] Data abort info:<br /> [ 22.991934][ T1] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000<br /> [ 22.991934][ T1] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 22.991934][ T1] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 22.991934][ T1] [0000000109170ffc] user address but active_mm is swapper<br /> [ 22.991934][ T1] Internal error: Oops: 0000000096000007 [#1] PREEMPT SMP<br /> [ 22.991934][ T1] Dumping ftrace buffer:<br /> [ 22.991934][ T1] (ftrace buffer empty)<br /> [ 22.991934][ T1] Modules linked in:<br /> [ 22.991934][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.98-android15-8-g0b1d2aee7fc3-dirty-4k #1 688c7060a825a3ac418fe53881730b355915a419<br /> [ 22.991934][ T1] Hardware name: Unisoc UMS9360-base Board (DT)<br /> [ 22.991934][ T1] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 22.991934][ T1] pc : swsusp_arch_resume+0x2ac/0x344<br /> [ 22.991934][ T1] lr : swsusp_arch_resume+0x294/0x344<br /> [ 22.991934][ T1] sp : ffffffc08006b960<br /> [ 22.991934][ T1] x29: ffffffc08006b9c0 x28: 0000000000000000 x27: 0000000000000000<br /> [ 22.991934][ T1] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000820<br /> [ 22.991934][ T1] x23: ffffffd0817e3000 x22: ffffffd0817e3000 x21: 0000000000000000<br /> [ 22.991934][ T1] x20: ffffff8089171000 x19: ffffffd08252c8c8 x18: ffffffc080061058<br /> [ 22.991934][ T1] x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 0000000000000004<br /> [ 22.991934][ T1] x14: ffffff8178c88000 x13: 0000000000000006 x12: 0000000000000000<br /> [ 22.991934][ T1] x11: 0000000000000015 x10: 0000000000000001 x9 : ffffffd082533000<br /> [ 22.991934][ T1] x8 : 0000000109171000 x7 : 205b5d3433393139 x6 : 392e32322020205b<br /> [ 22.991934][ T1] x5 : 000000010916f000 x4 : 000000008164b000 x3 : ffffff808a4e0530<br /> [ 22.991934][ T1] x2 : ffffffd08058e784 x1 : 0000000082326000 x0 : 000000010a283000<br /> [ 22.991934][ T1] Call trace:<br /> [ 22.991934][ T1] swsusp_arch_resume+0x2ac/0x344<br /> [ 22.991934][ T1] hibernation_restore+0x158/0x18c<br /> [ 22.991934][ T1] load_image_and_restore+0xb0/0xec<br /> [ 22.991934][ T1] software_resume+0xf4/0x19c<br /> [ 22.991934][ T1] software_resume_initcall+0x34/0x78<br /> [ 22.991934][ T1] do_one_initcall+0xe8/0x370<br /> [ 22.991934][ T1] do_initcall_level+0xc8/0x19c<br /> [ 22.991934][ T1] do_initcalls+0x70/0xc0<br /> [ 22.991934][ T1] do_basic_setup+0x1c/0x28<br /> [ 22.991934][ T1] kernel_init_freeable+0xe0/0x148<br /> [ 22.991934][ T1] kernel_init+0x20/0x1a8<br /> [ 22.991934][ T1] ret_from_fork+0x10/0x20<br /> [ 22.991934][ T1] Code: a9400a61 f94013e0 f9438923 f9400a64 (b85fc110)<br /> <br /> [catalin.marinas@arm.com: commit log updated by Mark Rutland]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dpll: Prevent duplicate registrations<br /> <br /> Modify the internal registration helpers dpll_xa_ref_{dpll,pin}_add()<br /> to reject duplicate registration attempts.<br /> <br /> Previously, if a caller attempted to register the same pin multiple<br /> times (with the same ops, priv, and cookie) on the same device, the core<br /> silently increments the reference count and return success. This behavior<br /> is incorrect because if the caller makes these duplicate registrations<br /> then for the first one dpll_pin_registration is allocated and for others<br /> the associated dpll_pin_ref.refcount is incremented. During the first<br /> unregistration the associated dpll_pin_registration is freed and for<br /> others WARN is fired.<br /> <br /> Fix this by updating the logic to return `-EEXIST` if a matching<br /> registration is found to enforce a strict "register once" policy.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix dead lock while flushing management frames<br /> <br /> Commit [1] converted the management transmission work item into a<br /> wiphy work. Since a wiphy work can only run under wiphy lock<br /> protection, a race condition happens in below scenario:<br /> <br /> 1. a management frame is queued for transmission.<br /> 2. ath12k_mac_op_flush() gets called to flush pending frames associated<br /> with the hardware (i.e, vif being NULL). Then in ath12k_mac_flush()<br /> the process waits for the transmission done.<br /> 3. Since wiphy lock has been taken by the flush process, the transmission<br /> work item has no chance to run, hence the dead lock.<br /> <br /> &gt;From user view, this dead lock results in below issue:<br /> <br /> wlp8s0: authenticate with xxxxxx (local address=xxxxxx)<br /> wlp8s0: send auth to xxxxxx (try 1/3)<br /> wlp8s0: authenticate with xxxxxx (local address=xxxxxx)<br /> wlp8s0: send auth to xxxxxx (try 1/3)<br /> wlp8s0: authenticated<br /> wlp8s0: associate with xxxxxx (try 1/3)<br /> wlp8s0: aborting association with xxxxxx by local choice (Reason: 3=DEAUTH_LEAVING)<br /> ath12k_pci 0000:08:00.0: failed to flush mgmt transmit queue, mgmt pkts pending 1<br /> <br /> The dead lock can be avoided by invoking wiphy_work_flush() to proactively<br /> run the queued work item. Note actually it is already present in<br /> ath12k_mac_op_flush(), however it does not protect the case where vif<br /> being NULL. Hence move it ahead to cover this case as well.<br /> <br /> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: hp-bioscfg: Fix kobject warnings for empty attribute names<br /> <br /> The hp-bioscfg driver attempts to register kobjects with empty names when<br /> the HP BIOS returns attributes with empty name strings. This causes<br /> multiple kernel warnings:<br /> <br /> kobject: (00000000135fb5e6): attempted to be registered with empty name!<br /> WARNING: CPU: 14 PID: 3336 at lib/kobject.c:219 kobject_add_internal+0x2eb/0x310<br /> <br /> Add validation in hp_init_bios_buffer_attribute() to check if the<br /> attribute name is empty after parsing it from the WMI buffer. If empty,<br /> log a debug message and skip registration of that attribute, allowing the<br /> module to continue processing other valid attributes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: provide a net pointer to __skb_flow_dissect()<br /> <br /> After 3cbf4ffba5ee ("net: plumb network namespace into __skb_flow_dissect")<br /> we have to provide a net pointer to __skb_flow_dissect(),<br /> either via skb-&gt;dev, skb-&gt;sk, or a user provided pointer.<br /> <br /> In the following case, syzbot was able to cook a bare skb.<br /> <br /> WARNING: net/core/flow_dissector.c:1131 at __skb_flow_dissect+0xb57/0x68b0 net/core/flow_dissector.c:1131, CPU#1: syz.2.1418/11053<br /> Call Trace:<br /> <br /> bond_flow_dissect drivers/net/bonding/bond_main.c:4093 [inline]<br /> __bond_xmit_hash+0x2d7/0xba0 drivers/net/bonding/bond_main.c:4157<br /> bond_xmit_hash_xdp drivers/net/bonding/bond_main.c:4208 [inline]<br /> bond_xdp_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5139 [inline]<br /> bond_xdp_get_xmit_slave+0x1fd/0x710 drivers/net/bonding/bond_main.c:5515<br /> xdp_master_redirect+0x13f/0x2c0 net/core/filter.c:4388<br /> bpf_prog_run_xdp include/net/xdp.h:700 [inline]<br /> bpf_test_run+0x6b2/0x7d0 net/bpf/test_run.c:421<br /> bpf_prog_test_run_xdp+0x795/0x10e0 net/bpf/test_run.c:1390<br /> bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4703<br /> __sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6182<br /> __do_sys_bpf kernel/bpf/syscall.c:6274 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:6272 [inline]<br /> __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> l2tp: avoid one data-race in l2tp_tunnel_del_work()<br /> <br /> We should read sk-&gt;sk_socket only when dealing with kernel sockets.<br /> <br /> syzbot reported the following data-race:<br /> <br /> BUG: KCSAN: data-race in l2tp_tunnel_del_work / sk_common_release<br /> <br /> write to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0:<br /> sk_set_socket include/net/sock.h:2092 [inline]<br /> sock_orphan include/net/sock.h:2118 [inline]<br /> sk_common_release+0xae/0x230 net/core/sock.c:4003<br /> udp_lib_close+0x15/0x20 include/net/udp.h:325<br /> inet_release+0xce/0xf0 net/ipv4/af_inet.c:437<br /> __sock_release net/socket.c:662 [inline]<br /> sock_close+0x6b/0x150 net/socket.c:1455<br /> __fput+0x29b/0x650 fs/file_table.c:468<br /> ____fput+0x1c/0x30 fs/file_table.c:496<br /> task_work_run+0x131/0x1a0 kernel/task_work.c:233<br /> resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]<br /> __exit_to_user_mode_loop kernel/entry/common.c:44 [inline]<br /> exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75<br /> __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]<br /> syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]<br /> syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline]<br /> syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline]<br /> do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> read to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1:<br /> l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418<br /> process_one_work kernel/workqueue.c:3257 [inline]<br /> process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340<br /> worker_thread+0x582/0x770 kernel/workqueue.c:3421<br /> kthread+0x489/0x510 kernel/kthread.c:463<br /> ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246<br /> <br /> value changed: 0xffff88811b818000 -&gt; 0x0000000000000000

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mISDN: annotate data-race around dev-&gt;work<br /> <br /> dev-&gt;work can re read locklessly in mISDN_read()<br /> and mISDN_poll(). Add READ_ONCE()/WRITE_ONCE() annotations.<br /> <br /> BUG: KCSAN: data-race in mISDN_ioctl / mISDN_read<br /> <br /> write to 0xffff88812d848280 of 4 bytes by task 10864 on cpu 1:<br /> misdn_add_timer drivers/isdn/mISDN/timerdev.c:175 [inline]<br /> mISDN_ioctl+0x2fb/0x550 drivers/isdn/mISDN/timerdev.c:233<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl+0xce/0x140 fs/ioctl.c:583<br /> __x64_sys_ioctl+0x43/0x50 fs/ioctl.c:583<br /> x64_sys_call+0x14b0/0x3000 arch/x86/include/generated/asm/syscalls_64.h:17<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> read to 0xffff88812d848280 of 4 bytes by task 10857 on cpu 0:<br /> mISDN_read+0x1f2/0x470 drivers/isdn/mISDN/timerdev.c:112<br /> do_loop_readv_writev fs/read_write.c:847 [inline]<br /> vfs_readv+0x3fb/0x690 fs/read_write.c:1020<br /> do_readv+0xe7/0x210 fs/read_write.c:1080<br /> __do_sys_readv fs/read_write.c:1165 [inline]<br /> __se_sys_readv fs/read_write.c:1162 [inline]<br /> __x64_sys_readv+0x45/0x50 fs/read_write.c:1162<br /> x64_sys_call+0x2831/0x3000 arch/x86/include/generated/asm/syscalls_64.h:20<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> value changed: 0x00000000 -&gt; 0x00000001

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igc: Reduce TSN TX packet buffer from 7KB to 5KB per queue<br /> <br /> The previous 7 KB per queue caused TX unit hangs under heavy<br /> timestamping load. Reducing to 5 KB avoids these hangs and matches<br /> the TSN recommendation in I225/I226 SW User Manual Section 7.5.4.<br /> <br /> The 8 KB "freed" by this change is currently unused. This reduction<br /> is not expected to impact throughput, as the i226 is PCIe-limited<br /> for small TSN packets rather than TX-buffer-limited.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> interconnect: debugfs: initialize src_node and dst_node to empty strings<br /> <br /> The debugfs_create_str() API assumes that the string pointer is either NULL<br /> or points to valid kmalloc() memory. Leaving the pointer uninitialized can<br /> cause problems.<br /> <br /> Initialize src_node and dst_node to empty strings before creating the<br /> debugfs entries to guarantee that reads and writes are safe.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: annotate data-race in ndisc_router_discovery()<br /> <br /> syzbot found that ndisc_router_discovery() could read and write<br /> in6_dev-&gt;ra_mtu without holding a lock [1]<br /> <br /> This looks fine, IFLA_INET6_RA_MTU is best effort.<br /> <br /> Add READ_ONCE()/WRITE_ONCE() to document the race.<br /> <br /> Note that we might also reject illegal MTU values<br /> (mtu skb-&gt;dev-&gt;mtu) in a future patch.<br /> <br /> [1]<br /> BUG: KCSAN: data-race in ndisc_router_discovery / ndisc_router_discovery<br /> <br /> read to 0xffff888119809c20 of 4 bytes by task 25817 on cpu 1:<br /> ndisc_router_discovery+0x151d/0x1c90 net/ipv6/ndisc.c:1558<br /> ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841<br /> icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989<br /> ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438<br /> ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489<br /> NF_HOOK include/linux/netfilter.h:318 [inline]<br /> ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500<br /> ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590<br /> dst_input include/net/dst.h:474 [inline]<br /> ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79<br /> ...<br /> <br /> write to 0xffff888119809c20 of 4 bytes by task 25816 on cpu 0:<br /> ndisc_router_discovery+0x155a/0x1c90 net/ipv6/ndisc.c:1559<br /> ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841<br /> icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989<br /> ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438<br /> ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489<br /> NF_HOOK include/linux/netfilter.h:318 [inline]<br /> ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500<br /> ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590<br /> dst_input include/net/dst.h:474 [inline]<br /> ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79<br /> ...<br /> <br /> value changed: 0x00000000 -&gt; 0xe5400659

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INIT<br /> <br /> A null-ptr-deref was reported in the SCTP transmit path when SCTP-AUTH key<br /> initialization fails:<br /> <br /> ==================================================================<br /> KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]<br /> CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2<br /> RIP: 0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline]<br /> RIP: 0010:sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401<br /> Call Trace:<br /> <br /> sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189<br /> sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111<br /> sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217<br /> sctp_cmd_interpreter.isra.0+0x19a5/0x62c0 net/sctp/sm_sideeffect.c:1787<br /> sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline]<br /> sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169<br /> sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c:1052<br /> sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88<br /> sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243<br /> sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127<br /> <br /> The issue is triggered when sctp_auth_asoc_init_active_key() fails in<br /> sctp_sf_do_5_1C_ack() while processing an INIT_ACK. In this case, the<br /> command sequence is currently:<br /> <br /> - SCTP_CMD_PEER_INIT<br /> - SCTP_CMD_TIMER_STOP (T1_INIT)<br /> - SCTP_CMD_TIMER_START (T1_COOKIE)<br /> - SCTP_CMD_NEW_STATE (COOKIE_ECHOED)<br /> - SCTP_CMD_ASSOC_SHKEY<br /> - SCTP_CMD_GEN_COOKIE_ECHO<br /> <br /> If SCTP_CMD_ASSOC_SHKEY fails, asoc-&gt;shkey remains NULL, while<br /> asoc-&gt;peer.auth_capable and asoc-&gt;peer.peer_chunks have already been set by<br /> SCTP_CMD_PEER_INIT. This allows a DATA chunk with auth = 1 and shkey = NULL<br /> to be queued by sctp_datamsg_from_user().<br /> <br /> Since command interpretation stops on failure, no COOKIE_ECHO should been<br /> sent via SCTP_CMD_GEN_COOKIE_ECHO. However, the T1_COOKIE timer has already<br /> been started, and it may enqueue a COOKIE_ECHO into the outqueue later. As<br /> a result, the DATA chunk can be transmitted together with the COOKIE_ECHO<br /> in sctp_outq_flush_data(), leading to the observed issue.<br /> <br /> Similar to the other places where it calls sctp_auth_asoc_init_active_key()<br /> right after sctp_process_init(), this patch moves the SCTP_CMD_ASSOC_SHKEY<br /> immediately after SCTP_CMD_PEER_INIT, before stopping T1_INIT and starting<br /> T1_COOKIE. This ensures that if shared key generation fails, authenticated<br /> DATA cannot be sent. It also allows the T1_INIT timer to retransmit INIT,<br /> giving the client another chance to process INIT_ACK and retry key setup.