Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: Fix use-after-free of kernel socket in cleanup_bearer().<br /> <br /> syzkaller reported a use-after-free of UDP kernel socket<br /> in cleanup_bearer() without repro. [0][1]<br /> <br /> When bearer_disable() calls tipc_udp_disable(), cleanup<br /> of the UDP kernel socket is deferred by work calling<br /> cleanup_bearer().<br /> <br /> tipc_exit_net() waits for such works to finish by checking<br /> tipc_net(net)-&gt;wq_count. However, the work decrements the<br /> count too early before releasing the kernel socket,<br /> unblocking cleanup_net() and resulting in use-after-free.<br /> <br /> Let&amp;#39;s move the decrement after releasing the socket in<br /> cleanup_bearer().<br /> <br /> [0]:<br /> ref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at<br /> sk_alloc+0x438/0x608<br /> inet_create+0x4c8/0xcb0<br /> __sock_create+0x350/0x6b8<br /> sock_create_kern+0x58/0x78<br /> udp_sock_create4+0x68/0x398<br /> udp_sock_create+0x88/0xc8<br /> tipc_udp_enable+0x5e8/0x848<br /> __tipc_nl_bearer_enable+0x84c/0xed8<br /> tipc_nl_bearer_enable+0x38/0x60<br /> genl_family_rcv_msg_doit+0x170/0x248<br /> genl_rcv_msg+0x400/0x5b0<br /> netlink_rcv_skb+0x1dc/0x398<br /> genl_rcv+0x44/0x68<br /> netlink_unicast+0x678/0x8b0<br /> netlink_sendmsg+0x5e4/0x898<br /> ____sys_sendmsg+0x500/0x830<br /> <br /> [1]:<br /> BUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline]<br /> BUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979<br /> udp_hashslot include/net/udp.h:85 [inline]<br /> udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979<br /> sk_common_release+0xaf/0x3f0 net/core/sock.c:3820<br /> inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437<br /> inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489<br /> __sock_release net/socket.c:658 [inline]<br /> sock_release+0xa0/0x210 net/socket.c:686<br /> cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819<br /> process_one_work kernel/workqueue.c:3229 [inline]<br /> process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310<br /> worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391<br /> kthread+0x531/0x6b0 kernel/kthread.c:389<br /> ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244<br /> <br /> Uninit was created at:<br /> slab_free_hook mm/slub.c:2269 [inline]<br /> slab_free mm/slub.c:4580 [inline]<br /> kmem_cache_free+0x207/0xc40 mm/slub.c:4682<br /> net_free net/core/net_namespace.c:454 [inline]<br /> cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647<br /> process_one_work kernel/workqueue.c:3229 [inline]<br /> process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310<br /> worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391<br /> kthread+0x531/0x6b0 kernel/kthread.c:389<br /> ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244<br /> <br /> CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> Workqueue: events cleanup_bearer

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-tcp: fix the memleak while create new ctrl failed<br /> <br /> Now while we create new ctrl failed, we have not free the<br /> tagset occupied by admin_q, here try to fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: dev: can_set_termination(): allow sleeping GPIOs<br /> <br /> In commit 6e86a1543c37 ("can: dev: provide optional GPIO based<br /> termination support") GPIO based termination support was added.<br /> <br /> For no particular reason that patch uses gpiod_set_value() to set the<br /> GPIO. This leads to the following warning, if the systems uses a<br /> sleeping GPIO, i.e. behind an I2C port expander:<br /> <br /> | WARNING: CPU: 0 PID: 379 at /drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x50/0x6c<br /> | CPU: 0 UID: 0 PID: 379 Comm: ip Not tainted 6.11.0-20241016-1 #1 823affae360cc91126e4d316d7a614a8bf86236c<br /> <br /> Replace gpiod_set_value() by gpiod_set_value_cansleep() to allow the<br /> use of sleeping GPIOs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix Out-of-Bounds Write in ksmbd_vfs_stream_write<br /> <br /> An offset from client could be a negative value, It could allows<br /> to write data outside the bounds of the allocated buffer.<br /> Note that this issue is coming when setting<br /> &amp;#39;vfs objects = streams_xattr parameter&amp;#39; in ksmbd.conf.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix Out-of-Bounds Read in ksmbd_vfs_stream_read<br /> <br /> An offset from client could be a negative value, It could lead<br /> to an out-of-bounds read from the stream_buf.<br /> Note that this issue is coming when setting<br /> &amp;#39;vfs objects = streams_xattr parameter&amp;#39; in ksmbd.conf.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Add architecture specific huge_pte_clear()<br /> <br /> When executing mm selftests run_vmtests.sh, there is such an error:<br /> <br /> BUG: Bad page state in process uffd-unit-tests pfn:00000<br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x0<br /> flags: 0xffff0000002000(reserved|node=0|zone=0|lastcpupid=0xffff)<br /> raw: 00ffff0000002000 ffffbf0000000008 ffffbf0000000008 0000000000000000<br /> raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000<br /> page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set<br /> Modules linked in: snd_seq_dummy snd_seq snd_seq_device rfkill vfat fat<br /> virtio_balloon efi_pstore virtio_net pstore net_failover failover fuse<br /> nfnetlink virtio_scsi virtio_gpu virtio_dma_buf dm_multipath efivarfs<br /> CPU: 2 UID: 0 PID: 1913 Comm: uffd-unit-tests Not tainted 6.12.0 #184<br /> Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022<br /> Stack : 900000047c8ac000 0000000000000000 9000000000223a7c 900000047c8ac000<br /> 900000047c8af690 900000047c8af698 0000000000000000 900000047c8af7d8<br /> 900000047c8af7d0 900000047c8af7d0 900000047c8af5b0 0000000000000001<br /> 0000000000000001 900000047c8af698 10b3c7d53da40d26 0000010000000000<br /> 0000000000000022 0000000fffffffff fffffffffe000000 ffff800000000000<br /> 000000000000002f 0000800000000000 000000017a6d4000 90000000028f8940<br /> 0000000000000000 0000000000000000 90000000025aa5e0 9000000002905000<br /> 0000000000000000 90000000028f8940 ffff800000000000 0000000000000000<br /> 0000000000000000 0000000000000000 9000000000223a94 000000012001839c<br /> 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d<br /> ...<br /> Call Trace:<br /> [] show_stack+0x5c/0x180<br /> [] dump_stack_lvl+0x6c/0xa0<br /> [] bad_page+0x1a0/0x1f0<br /> [] free_unref_folios+0xbf0/0xd20<br /> [] folios_put_refs+0x1a4/0x2b8<br /> [] free_pages_and_swap_cache+0x164/0x260<br /> [] tlb_batch_pages_flush+0xa8/0x1c0<br /> [] tlb_finish_mmu+0xa8/0x218<br /> [] exit_mmap+0x1a0/0x360<br /> [] __mmput+0x78/0x200<br /> [] do_exit+0x43c/0xde8<br /> [] do_group_exit+0x68/0x110<br /> [] sys_exit_group+0x1c/0x20<br /> [] do_syscall+0x94/0x130<br /> [] handle_syscall+0xb8/0x158<br /> Disabling lock debugging due to kernel taint<br /> BUG: non-zero pgtables_bytes on freeing mm: -16384<br /> <br /> On LoongArch system, invalid huge pte entry should be invalid_pte_table<br /> or a single _PAGE_HUGE bit rather than a zero value. And it should be<br /> the same with invalid pmd entry, since pmd_none() is called by function<br /> free_pgd_range() and pmd_none() return 0 by huge_pte_clear(). So single<br /> _PAGE_HUGE bit is also treated as a valid pte table and free_pte_range()<br /> will be called in free_pmd_range().<br /> <br /> free_pmd_range()<br /> pmd = pmd_offset(pud, addr);<br /> do {<br /> next = pmd_addr_end(addr, end);<br /> if (pmd_none_or_clear_bad(pmd))<br /> continue;<br /> free_pte_range(tlb, pmd, addr);<br /> } while (pmd++, addr = next, addr != end);<br /> <br /> Here invalid_pte_table is used for both invalid huge pte entry and<br /> pmd entry.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: wacom: fix when get product name maybe null pointer<br /> <br /> Due to incorrect dev-&gt;product reporting by certain devices, null<br /> pointer dereferences occur when dev-&gt;product is empty, leading to<br /> potential system crashes.<br /> <br /> This issue was found on EXCELSIOR DL37-D05 device with<br /> Loongson-LS3A6000-7A2000-DL37 motherboard.<br /> <br /> Kernel logs:<br /> [ 56.470885] usb 4-3: new full-speed USB device number 4 using ohci-pci<br /> [ 56.671638] usb 4-3: string descriptor 0 read error: -22<br /> [ 56.671644] usb 4-3: New USB device found, idVendor=056a, idProduct=0374, bcdDevice= 1.07<br /> [ 56.671647] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3<br /> [ 56.678839] hid-generic 0003:056A:0374.0004: hiddev0,hidraw3: USB HID v1.10 Device [HID 056a:0374] on usb-0000:00:05.0-3/input0<br /> [ 56.697719] CPU 2 Unable to handle kernel paging request at virtual address 0000000000000000, era == 90000000066e35c8, ra == ffff800004f98a80<br /> [ 56.697732] Oops[#1]:<br /> [ 56.697734] CPU: 2 PID: 2742 Comm: (udev-worker) Tainted: G OE 6.6.0-loong64-desktop #25.00.2000.015<br /> [ 56.697737] Hardware name: Inspur CE520L2/C09901N000000000, BIOS 2.09.00 10/11/2024<br /> [ 56.697739] pc 90000000066e35c8 ra ffff800004f98a80 tp 9000000125478000 sp 900000012547b8a0<br /> [ 56.697741] a0 0000000000000000 a1 ffff800004818b28 a2 0000000000000000 a3 0000000000000000<br /> [ 56.697743] a4 900000012547b8f0 a5 0000000000000000 a6 0000000000000000 a7 0000000000000000<br /> [ 56.697745] t0 ffff800004818b2d t1 0000000000000000 t2 0000000000000003 t3 0000000000000005<br /> [ 56.697747] t4 0000000000000000 t5 0000000000000000 t6 0000000000000000 t7 0000000000000000<br /> [ 56.697748] t8 0000000000000000 u0 0000000000000000 s9 0000000000000000 s0 900000011aa48028<br /> [ 56.697750] s1 0000000000000000 s2 0000000000000000 s3 ffff800004818e80 s4 ffff800004810000<br /> [ 56.697751] s5 90000001000b98d0 s6 ffff800004811f88 s7 ffff800005470440 s8 0000000000000000<br /> [ 56.697753] ra: ffff800004f98a80 wacom_update_name+0xe0/0x300 [wacom]<br /> [ 56.697802] ERA: 90000000066e35c8 strstr+0x28/0x120<br /> [ 56.697806] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)<br /> [ 56.697816] PRMD: 0000000c (PPLV0 +PIE +PWE)<br /> [ 56.697821] EUEN: 00000000 (-FPE -SXE -ASXE -BTE)<br /> [ 56.697827] ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)<br /> [ 56.697831] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)<br /> [ 56.697835] BADV: 0000000000000000<br /> [ 56.697836] PRID: 0014d000 (Loongson-64bit, Loongson-3A6000)<br /> [ 56.697838] Modules linked in: wacom(+) bnep bluetooth rfkill qrtr nls_iso8859_1 nls_cp437 snd_hda_codec_conexant snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore input_leds mousedev led_class joydev deepin_netmonitor(OE) fuse nfnetlink dmi_sysfs ip_tables x_tables overlay amdgpu amdxcp drm_exec gpu_sched drm_buddy radeon drm_suballoc_helper i2c_algo_bit drm_ttm_helper r8169 ttm drm_display_helper spi_loongson_pci xhci_pci cec xhci_pci_renesas spi_loongson_core hid_generic realtek gpio_loongson_64bit<br /> [ 56.697887] Process (udev-worker) (pid: 2742, threadinfo=00000000aee0d8b4, task=00000000a9eff1f3)<br /> [ 56.697890] Stack : 0000000000000000 ffff800004817e00 0000000000000000 0000251c00000000<br /> [ 56.697896] 0000000000000000 00000011fffffffd 0000000000000000 0000000000000000<br /> [ 56.697901] 0000000000000000 1b67a968695184b9 0000000000000000 90000001000b98d0<br /> [ 56.697906] 90000001000bb8d0 900000011aa48028 0000000000000000 ffff800004f9d74c<br /> [ 56.697911] 90000001000ba000 ffff800004f9ce58 0000000000000000 ffff800005470440<br /> [ 56.697916] ffff800004811f88 90000001000b98d0 9000000100da2aa8 90000001000bb8d0<br /> [ 56.697921] 0000000000000000 90000001000ba000 900000011aa48028 ffff800004f9d74c<br /> [ 56.697926] ffff8000054704e8 90000001000bb8b8 90000001000ba000 0000000000000000<br /> [ 56.697931] 90000001000bb8d0 <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: free inode when ocfs2_get_init_inode() fails<br /> <br /> syzbot is reporting busy inodes after unmount, for commit 9c89fe0af826<br /> ("ocfs2: Handle error from dquot_initialize()") forgot to call iput() when<br /> new_inode() succeeded and dquot_initialize() failed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: sg: Fix slab-use-after-free read in sg_release()<br /> <br /> Fix a use-after-free bug in sg_release(), detected by syzbot with KASAN:<br /> <br /> BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30<br /> kernel/locking/lockdep.c:5838<br /> __mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912<br /> sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407<br /> <br /> In sg_release(), the function kref_put(&amp;sfp-&gt;f_ref, sg_remove_sfp) is<br /> called before releasing the open_rel_lock mutex. The kref_put() call may<br /> decrement the reference count of sfp to zero, triggering its cleanup<br /> through sg_remove_sfp(). This cleanup includes scheduling deferred work<br /> via sg_remove_sfp_usercontext(), which ultimately frees sfp.<br /> <br /> After kref_put(), sg_release() continues to unlock open_rel_lock and may<br /> reference sfp or sdp. If sfp has already been freed, this results in a<br /> slab-use-after-free error.<br /> <br /> Move the kref_put(&amp;sfp-&gt;f_ref, sg_remove_sfp) call after unlocking the<br /> open_rel_lock mutex. This ensures:<br /> <br /> - No references to sfp or sdp occur after the reference count is<br /> decremented.<br /> <br /> - Cleanup functions such as sg_remove_sfp() and<br /> sg_remove_sfp_usercontext() can safely execute without impacting the<br /> mutex handling in sg_release().<br /> <br /> The fix has been tested and validated by syzbot. This patch closes the<br /> bug reported at the following syzkaller link and ensures proper<br /> sequencing of resource cleanup and mutex operations, eliminating the<br /> risk of use-after-free errors in sg_release().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsg<br /> <br /> The current sk memory accounting logic in __SK_REDIRECT is pre-uncharging<br /> tosend bytes, which is either msg-&gt;sg.size or a smaller value apply_bytes.<br /> <br /> Potential problems with this strategy are as follows:<br /> <br /> - If the actual sent bytes are smaller than tosend, we need to charge some<br /> bytes back, as in line 487, which is okay but seems not clean.<br /> <br /> - When tosend is set to apply_bytes, as in line 417, and (ret sg.size - apply_bytes) bytes.<br /> <br /> [...]<br /> 415 tosend = msg-&gt;sg.size;<br /> 416 if (psock-&gt;apply_bytes &amp;&amp; psock-&gt;apply_bytes apply_bytes;<br /> [...]<br /> 443 sk_msg_return(sk, msg, tosend);<br /> 444 release_sock(sk);<br /> 446 origsize = msg-&gt;sg.size;<br /> 447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress,<br /> 448 msg, tosend, flags);<br /> 449 sent = origsize - msg-&gt;sg.size;<br /> [...]<br /> 454 lock_sock(sk);<br /> 455 if (unlikely(ret

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cacheinfo: Allocate memory during CPU hotplug if not done from the primary CPU<br /> <br /> Commit<br /> <br /> 5944ce092b97 ("arch_topology: Build cacheinfo from primary CPU")<br /> <br /> adds functionality that architectures can use to optionally allocate and<br /> build cacheinfo early during boot. Commit<br /> <br /> 6539cffa9495 ("cacheinfo: Add arch specific early level initializer")<br /> <br /> lets secondary CPUs correct (and reallocate memory) cacheinfo data if<br /> needed.<br /> <br /> If the early build functionality is not used and cacheinfo does not need<br /> correction, memory for cacheinfo is never allocated. x86 does not use<br /> the early build functionality. Consequently, during the cacheinfo CPU<br /> hotplug callback, last_level_cache_is_valid() attempts to dereference<br /> a NULL pointer:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000100<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] PREEPMT SMP NOPTI<br /> CPU: 0 PID 19 Comm: cpuhp/0 Not tainted 6.4.0-rc2 #1<br /> RIP: 0010: last_level_cache_is_valid+0x95/0xe0a<br /> <br /> Allocate memory for cacheinfo during the cacheinfo CPU hotplug callback<br /> if not done earlier.<br /> <br /> Moreover, before determining the validity of the last-level cache info,<br /> ensure that it has been allocated. Simply checking for non-zero<br /> cache_leaves() is not sufficient, as some architectures (e.g., Intel<br /> processors) have non-zero cache_leaves() before allocation.<br /> <br /> Dereferencing NULL cacheinfo can occur in update_per_cpu_data_slice_size().<br /> This function iterates over all online CPUs. However, a CPU may have come<br /> online recently, but its cacheinfo may not have been allocated yet.<br /> <br /> While here, remove an unnecessary indentation in allocate_cache_info().<br /> <br /> [ bp: Massage. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pmdomain: imx: gpcv2: Adjust delay after power up handshake<br /> <br /> The udelay(5) is not enough, sometimes below kernel panic<br /> still be triggered:<br /> <br /> [ 4.012973] Kernel panic - not syncing: Asynchronous SError Interrupt<br /> [ 4.012976] CPU: 2 UID: 0 PID: 186 Comm: (udev-worker) Not tainted 6.12.0-rc2-0.0.0-devel-00004-g8b1b79e88956 #1<br /> [ 4.012982] Hardware name: Toradex Verdin iMX8M Plus WB on Dahlia Board (DT)<br /> [ 4.012985] Call trace:<br /> [...]<br /> [ 4.013029] arm64_serror_panic+0x64/0x70<br /> [ 4.013034] do_serror+0x3c/0x70<br /> [ 4.013039] el1h_64_error_handler+0x30/0x54<br /> [ 4.013046] el1h_64_error+0x64/0x68<br /> [ 4.013050] clk_imx8mp_audiomix_runtime_resume+0x38/0x48<br /> [ 4.013059] __genpd_runtime_resume+0x30/0x80<br /> [ 4.013066] genpd_runtime_resume+0x114/0x29c<br /> [ 4.013073] __rpm_callback+0x48/0x1e0<br /> [ 4.013079] rpm_callback+0x68/0x80<br /> [ 4.013084] rpm_resume+0x3bc/0x6a0<br /> [ 4.013089] __pm_runtime_resume+0x50/0x9c<br /> [ 4.013095] pm_runtime_get_suppliers+0x60/0x8c<br /> [ 4.013101] __driver_probe_device+0x4c/0x14c<br /> [ 4.013108] driver_probe_device+0x3c/0x120<br /> [ 4.013114] __driver_attach+0xc4/0x200<br /> [ 4.013119] bus_for_each_dev+0x7c/0xe0<br /> [ 4.013125] driver_attach+0x24/0x30<br /> [ 4.013130] bus_add_driver+0x110/0x240<br /> [ 4.013135] driver_register+0x68/0x124<br /> [ 4.013142] __platform_driver_register+0x24/0x30<br /> [ 4.013149] sdma_driver_init+0x20/0x1000 [imx_sdma]<br /> [ 4.013163] do_one_initcall+0x60/0x1e0<br /> [ 4.013168] do_init_module+0x5c/0x21c<br /> [ 4.013175] load_module+0x1a98/0x205c<br /> [ 4.013181] init_module_from_file+0x88/0xd4<br /> [ 4.013187] __arm64_sys_finit_module+0x258/0x350<br /> [ 4.013194] invoke_syscall.constprop.0+0x50/0xe0<br /> [ 4.013202] do_el0_svc+0xa8/0xe0<br /> [ 4.013208] el0_svc+0x3c/0x140<br /> [ 4.013215] el0t_64_sync_handler+0x120/0x12c<br /> [ 4.013222] el0t_64_sync+0x190/0x194<br /> [ 4.013228] SMP: stopping secondary CPUs<br /> <br /> The correct way is to wait handshake, but it needs BUS clock of<br /> BLK-CTL be enabled, which is in separate driver. So delay is the<br /> only option here. The udelay(10) is a data got by experiment.