Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> of_numa: fix uninitialized memory nodes causing kernel panic<br /> <br /> When there are memory-only nodes (nodes without CPUs), these nodes are not<br /> properly initialized, causing kernel panic during boot.<br /> <br /> of_numa_init<br /> of_numa_parse_cpu_nodes<br /> node_set(nid, numa_nodes_parsed);<br /> of_numa_parse_memory_nodes<br /> <br /> In of_numa_parse_cpu_nodes, numa_nodes_parsed gets updated only for nodes<br /> containing CPUs. Memory-only nodes should have been updated in<br /> of_numa_parse_memory_nodes, but they weren&amp;#39;t.<br /> <br /> Subsequently, when free_area_init() attempts to access NODE_DATA() for<br /> these uninitialized memory nodes, the kernel panics due to NULL pointer<br /> dereference.<br /> <br /> This can be reproduced on ARM64 QEMU with 1 CPU and 2 memory nodes:<br /> <br /> qemu-system-aarch64 \<br /> -cpu host -nographic \<br /> -m 4G -smp 1 \<br /> -machine virt,accel=kvm,gic-version=3,iommu=smmuv3 \<br /> -object memory-backend-ram,size=2G,id=mem0 \<br /> -object memory-backend-ram,size=2G,id=mem1 \<br /> -numa node,nodeid=0,memdev=mem0 \<br /> -numa node,nodeid=1,memdev=mem1 \<br /> -kernel $IMAGE \<br /> -hda $DISK \<br /> -append "console=ttyAMA0 root=/dev/vda rw earlycon"<br /> <br /> [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x481fd010]<br /> [ 0.000000] Linux version 6.17.0-rc1-00001-gabb4b3daf18c-dirty (yintirui@local) (gcc (GCC) 12.3.1, GNU ld (GNU Binutils) 2.41) #52 SMP PREEMPT Mon Aug 18 09:49:40 CST 2025<br /> [ 0.000000] KASLR enabled<br /> [ 0.000000] random: crng init done<br /> [ 0.000000] Machine model: linux,dummy-virt<br /> [ 0.000000] efi: UEFI not found.<br /> [ 0.000000] earlycon: pl11 at MMIO 0x0000000009000000 (options &amp;#39;&amp;#39;)<br /> [ 0.000000] printk: legacy bootconsole [pl11] enabled<br /> [ 0.000000] OF: reserved mem: Reserved memory: No reserved-memory node in the DT<br /> [ 0.000000] NODE_DATA(0) allocated [mem 0xbfffd9c0-0xbfffffff]<br /> [ 0.000000] node 1 must be removed before remove section 23<br /> [ 0.000000] Zone ranges:<br /> [ 0.000000] DMA [mem 0x0000000040000000-0x00000000ffffffff]<br /> [ 0.000000] DMA32 empty<br /> [ 0.000000] Normal [mem 0x0000000100000000-0x000000013fffffff]<br /> [ 0.000000] Movable zone start for each node<br /> [ 0.000000] Early memory node ranges<br /> [ 0.000000] node 0: [mem 0x0000000040000000-0x00000000bfffffff]<br /> [ 0.000000] node 1: [mem 0x00000000c0000000-0x000000013fffffff]<br /> [ 0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x00000000bfffffff]<br /> [ 0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0<br /> [ 0.000000] Mem abort info:<br /> [ 0.000000] ESR = 0x0000000096000004<br /> [ 0.000000] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 0.000000] SET = 0, FnV = 0<br /> [ 0.000000] EA = 0, S1PTW = 0<br /> [ 0.000000] FSC = 0x04: level 0 translation fault<br /> [ 0.000000] Data abort info:<br /> [ 0.000000] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> [ 0.000000] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 0.000000] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 0.000000] [00000000000000a0] user address but active_mm is swapper<br /> [ 0.000000] Internal error: Oops: 0000000096000004 [#1] SMP<br /> [ 0.000000] Modules linked in:<br /> [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.17.0-rc1-00001-g760c6dabf762-dirty #54 PREEMPT<br /> [ 0.000000] Hardware name: linux,dummy-virt (DT)<br /> [ 0.000000] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 0.000000] pc : free_area_init+0x50c/0xf9c<br /> [ 0.000000] lr : free_area_init+0x5c0/0xf9c<br /> [ 0.000000] sp : ffffa02ca0f33c00<br /> [ 0.000000] x29: ffffa02ca0f33cb0 x28: 0000000000000000 x27: 0000000000000000<br /> [ 0.000000] x26: 4ec4ec4ec4ec4ec5 x25: 00000000000c0000 x24: 00000000000c0000<br /> [ 0.000000] x23: 0000000000040000 x22: 0000000000000000 x21: ffffa02ca0f3b368<br /> [ 0.000000] x20: ffffa02ca14c7b98 x19: 0000000000000000 x18: 0000000000000002<br /> [ 0.000000] x17: 000000000000cacc x16: 0000000000000001 x15: 0000000000000001<br /> [ 0.000000] x14: 0000000080000000 x13: 0000000000000018 x12: 0000000000000002<br /> [ 0.0<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: kexec: initialize kexec_buf struct in load_other_segments()<br /> <br /> Patch series "kexec: Fix invalid field access".<br /> <br /> The kexec_buf structure was previously declared without initialization. <br /> commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly")<br /> added a field that is always read but not consistently populated by all<br /> architectures. This un-initialized field will contain garbage.<br /> <br /> This is also triggering a UBSAN warning when the uninitialized data was<br /> accessed:<br /> <br /> ------------[ cut here ]------------<br /> UBSAN: invalid-load in ./include/linux/kexec.h:210:10<br /> load of value 252 is not a valid value for type &amp;#39;_Bool&amp;#39;<br /> <br /> Zero-initializing kexec_buf at declaration ensures all fields are cleanly<br /> set, preventing future instances of uninitialized memory being used.<br /> <br /> An initial fix was already landed for arm64[0], and this patchset fixes<br /> the problem on the remaining arm64 code and on riscv, as raised by Mark.<br /> <br /> Discussions about this problem could be found at[1][2].<br /> <br /> <br /> This patch (of 3):<br /> <br /> The kexec_buf structure was previously declared without initialization.<br /> commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly")<br /> added a field that is always read but not consistently populated by all<br /> architectures. This un-initialized field will contain garbage.<br /> <br /> This is also triggering a UBSAN warning when the uninitialized data was<br /> accessed:<br /> <br /> ------------[ cut here ]------------<br /> UBSAN: invalid-load in ./include/linux/kexec.h:210:10<br /> load of value 252 is not a valid value for type &amp;#39;_Bool&amp;#39;<br /> <br /> Zero-initializing kexec_buf at declaration ensures all fields are<br /> cleanly set, preventing future instances of uninitialized memory being<br /> used.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phylink: add lock for serializing concurrent pl-&gt;phydev writes with resolver<br /> <br /> Currently phylink_resolve() protects itself against concurrent<br /> phylink_bringup_phy() or phylink_disconnect_phy() calls which modify<br /> pl-&gt;phydev by relying on pl-&gt;state_mutex.<br /> <br /> The problem is that in phylink_resolve(), pl-&gt;state_mutex is in a lock<br /> inversion state with pl-&gt;phydev-&gt;lock. So pl-&gt;phydev-&gt;lock needs to be<br /> acquired prior to pl-&gt;state_mutex. But that requires dereferencing<br /> pl-&gt;phydev in the first place, and without pl-&gt;state_mutex, that is<br /> racy.<br /> <br /> Hence the reason for the extra lock. Currently it is redundant, but it<br /> will serve a functional purpose once mutex_lock(&amp;phy-&gt;lock) will be<br /> moved outside of the mutex_lock(&amp;pl-&gt;state_mutex) section.<br /> <br /> Another alternative considered would have been to let phylink_resolve()<br /> acquire the rtnl_mutex, which is also held when phylink_bringup_phy()<br /> and phylink_disconnect_phy() are called. But since phylink_disconnect_phy()<br /> runs under rtnl_lock(), it would deadlock with phylink_resolve() when<br /> calling flush_work(&amp;pl-&gt;resolve). Additionally, it would have been<br /> undesirable because it would have unnecessarily blocked many other call<br /> paths as well in the entire kernel, so the smaller-scoped lock was<br /> preferred.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: remove oem i2c adapter on finish<br /> <br /> Fixes a bug where unbinding of the GPU would leave the oem i2c adapter<br /> registered resulting in a null pointer dereference when applications try<br /> to access the invalid device.<br /> <br /> (cherry picked from commit 89923fb7ead4fdd37b78dd49962d9bb5892403e6)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dev_ioctl: take ops lock in hwtstamp lower paths<br /> <br /> ndo hwtstamp callbacks are expected to run under the per-device ops<br /> lock. Make the lower get/set paths consistent with the rest of ndo<br /> invocations.<br /> <br /> Kernel log:<br /> WARNING: CPU: 13 PID: 51364 at ./include/net/netdev_lock.h:70 __netdev_update_features+0x4bd/0xe60<br /> ...<br /> RIP: 0010:__netdev_update_features+0x4bd/0xe60<br /> ...<br /> Call Trace:<br /> <br /> netdev_update_features+0x1f/0x60<br /> mlx5_hwtstamp_set+0x181/0x290 [mlx5_core]<br /> mlx5e_hwtstamp_set+0x19/0x30 [mlx5_core]<br /> dev_set_hwtstamp_phylib+0x9f/0x220<br /> dev_set_hwtstamp_phylib+0x9f/0x220<br /> dev_set_hwtstamp+0x13d/0x240<br /> dev_ioctl+0x12f/0x4b0<br /> sock_ioctl+0x171/0x370<br /> __x64_sys_ioctl+0x3f7/0x900<br /> ? __sys_setsockopt+0x69/0xb0<br /> do_syscall_64+0x6f/0x2e0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> ...<br /> <br /> ....<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Note that the mlx5_hwtstamp_set and mlx5e_hwtstamp_set functions shown<br /> in the trace come from an in progress patch converting the legacy ioctl<br /> to ndo_hwtstamp_get/set and are not present in mainline.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vmalloc, mm/kasan: respect gfp mask in kasan_populate_vmalloc()<br /> <br /> kasan_populate_vmalloc() and its helpers ignore the caller&amp;#39;s gfp_mask and<br /> always allocate memory using the hardcoded GFP_KERNEL flag. This makes<br /> them inconsistent with vmalloc(), which was recently extended to support<br /> GFP_NOFS and GFP_NOIO allocations.<br /> <br /> Page table allocations performed during shadow population also ignore the<br /> external gfp_mask. To preserve the intended semantics of GFP_NOFS and<br /> GFP_NOIO, wrap the apply_to_page_range() calls into the appropriate<br /> memalloc scope.<br /> <br /> xfs calls vmalloc with GFP_NOFS, so this bug could lead to deadlock.<br /> <br /> There was a report here<br /> https://lkml.kernel.org/r/686ea951.050a0220.385921.0016.GAE@google.com<br /> <br /> This patch:<br /> - Extends kasan_populate_vmalloc() and helpers to take gfp_mask;<br /> - Passes gfp_mask down to alloc_pages_bulk() and __get_free_page();<br /> - Enforces GFP_NOFS/NOIO semantics with memalloc_*_save()/restore()<br /> around apply_to_page_range();<br /> - Updates vmalloc.c and percpu allocator call sites accordingly.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: rawnand: stm32_fmc2: avoid overlapping mappings on ECC buffer<br /> <br /> Avoid below overlapping mappings by using a contiguous<br /> non-cacheable buffer.<br /> <br /> [ 4.077708] DMA-API: stm32_fmc2_nfc 48810000.nand-controller: cacheline tracking EEXIST,<br /> overlapping mappings aren&amp;#39;t supported<br /> [ 4.089103] WARNING: CPU: 1 PID: 44 at kernel/dma/debug.c:568 add_dma_entry+0x23c/0x300<br /> [ 4.097071] Modules linked in:<br /> [ 4.100101] CPU: 1 PID: 44 Comm: kworker/u4:2 Not tainted 6.1.82 #1<br /> [ 4.106346] Hardware name: STMicroelectronics STM32MP257F VALID1 SNOR / MB1704 (LPDDR4 Power discrete) + MB1703 + MB1708 (SNOR MB1730) (DT)<br /> [ 4.118824] Workqueue: events_unbound deferred_probe_work_func<br /> [ 4.124674] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 4.131624] pc : add_dma_entry+0x23c/0x300<br /> [ 4.135658] lr : add_dma_entry+0x23c/0x300<br /> [ 4.139792] sp : ffff800009dbb490<br /> [ 4.143016] x29: ffff800009dbb4a0 x28: 0000000004008022 x27: ffff8000098a6000<br /> [ 4.150174] x26: 0000000000000000 x25: ffff8000099e7000 x24: ffff8000099e7de8<br /> [ 4.157231] x23: 00000000ffffffff x22: 0000000000000000 x21: ffff8000098a6a20<br /> [ 4.164388] x20: ffff000080964180 x19: ffff800009819ba0 x18: 0000000000000006<br /> [ 4.171545] x17: 6361727420656e69 x16: 6c6568636163203a x15: 72656c6c6f72746e<br /> [ 4.178602] x14: 6f632d646e616e2e x13: ffff800009832f58 x12: 00000000000004ec<br /> [ 4.185759] x11: 00000000000001a4 x10: ffff80000988af58 x9 : ffff800009832f58<br /> [ 4.192916] x8 : 00000000ffffefff x7 : ffff80000988af58 x6 : 80000000fffff000<br /> [ 4.199972] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000<br /> [ 4.207128] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000812d2c40<br /> [ 4.214185] Call trace:<br /> [ 4.216605] add_dma_entry+0x23c/0x300<br /> [ 4.220338] debug_dma_map_sg+0x198/0x350<br /> [ 4.224373] __dma_map_sg_attrs+0xa0/0x110<br /> [ 4.228411] dma_map_sg_attrs+0x10/0x2c<br /> [ 4.232247] stm32_fmc2_nfc_xfer.isra.0+0x1c8/0x3fc<br /> [ 4.237088] stm32_fmc2_nfc_seq_read_page+0xc8/0x174<br /> [ 4.242127] nand_read_oob+0x1d4/0x8e0<br /> [ 4.245861] mtd_read_oob_std+0x58/0x84<br /> [ 4.249596] mtd_read_oob+0x90/0x150<br /> [ 4.253231] mtd_read+0x68/0xac

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/lru_sort: avoid divide-by-zero in damon_lru_sort_apply_parameters()<br /> <br /> Patch series "mm/damon: avoid divide-by-zero in DAMON module&amp;#39;s parameters<br /> application".<br /> <br /> DAMON&amp;#39;s RECLAIM and LRU_SORT modules perform no validation on<br /> user-configured parameters during application, which may lead to<br /> division-by-zero errors.<br /> <br /> Avoid the divide-by-zero by adding validation checks when DAMON modules<br /> attempt to apply the parameters.<br /> <br /> <br /> This patch (of 2):<br /> <br /> During the calculation of &amp;#39;hot_thres&amp;#39; and &amp;#39;cold_thres&amp;#39;, either<br /> &amp;#39;sample_interval&amp;#39; or &amp;#39;aggr_interval&amp;#39; is used as the divisor, which may<br /> lead to division-by-zero errors. Fix it by directly returning -EINVAL<br /> when such a case occurs. Additionally, since &amp;#39;aggr_interval&amp;#39; is already<br /> required to be set no smaller than &amp;#39;sample_interval&amp;#39; in damon_set_attrs(),<br /> only the case where &amp;#39;sample_interval&amp;#39; is zero needs to be checked.

*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched: Fix sched_numa_find_nth_cpu() if mask offline<br /> <br /> sched_numa_find_nth_cpu() uses a bsearch to look for the &amp;#39;closest&amp;#39;<br /> CPU in sched_domains_numa_masks and given cpus mask. However they<br /> might not intersect if all CPUs in the cpus mask are offline. bsearch<br /> will return NULL in that case, bail out instead of dereferencing a<br /> bogus pointer.<br /> <br /> The previous behaviour lead to this bug when using maxcpus=4 on an<br /> rk3399 (LLLLbb) (i.e. booting with all big CPUs offline):<br /> <br /> [ 1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000<br /> [ 1.423635] Mem abort info:<br /> [ 1.423889] ESR = 0x0000000096000006<br /> [ 1.424227] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 1.424715] SET = 0, FnV = 0<br /> [ 1.424995] EA = 0, S1PTW = 0<br /> [ 1.425279] FSC = 0x06: level 2 translation fault<br /> [ 1.425735] Data abort info:<br /> [ 1.425998] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000<br /> [ 1.426499] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 1.426952] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000<br /> [ 1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000<br /> [ 1.429014] Internal error: Oops: 0000000096000006 [#1] SMP<br /> [ 1.429525] Modules linked in:<br /> [ 1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT<br /> [ 1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT)<br /> [ 1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 1.431634] pc : sched_numa_find_nth_cpu+0x2a0/0x488<br /> [ 1.432094] lr : sched_numa_find_nth_cpu+0x284/0x488<br /> [ 1.432543] sp : ffffffc084e1b960<br /> [ 1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0<br /> [ 1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000<br /> [ 1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378<br /> [ 1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff<br /> [ 1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7<br /> [ 1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372<br /> [ 1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860<br /> [ 1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000<br /> [ 1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000<br /> [ 1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68<br /> [ 1.439332] Call trace:<br /> [ 1.439559] sched_numa_find_nth_cpu+0x2a0/0x488 (P)<br /> [ 1.440016] smp_call_function_any+0xc8/0xd0<br /> [ 1.440416] armv8_pmu_init+0x58/0x27c<br /> [ 1.440770] armv8_cortex_a72_pmu_init+0x20/0x2c<br /> [ 1.441199] arm_pmu_device_probe+0x1e4/0x5e8<br /> [ 1.441603] armv8_pmu_device_probe+0x1c/0x28<br /> [ 1.442007] platform_probe+0x5c/0xac<br /> [ 1.442347] really_probe+0xbc/0x298<br /> [ 1.442683] __driver_probe_device+0x78/0x12c<br /> [ 1.443087] driver_probe_device+0xdc/0x160<br /> [ 1.443475] __driver_attach+0x94/0x19c<br /> [ 1.443833] bus_for_each_dev+0x74/0xd4<br /> [ 1.444190] driver_attach+0x24/0x30<br /> [ 1.444525] bus_add_driver+0xe4/0x208<br /> [ 1.444874] driver_register+0x60/0x128<br /> [ 1.445233] __platform_driver_register+0x24/0x30<br /> [ 1.445662] armv8_pmu_driver_init+0x28/0x4c<br /> [ 1.446059] do_one_initcall+0x44/0x25c<br /> [ 1.446416] kernel_init_freeable+0x1dc/0x3bc<br /> [ 1.446820] kernel_init+0x20/0x1d8<br /> [ 1.447151] ret_from_fork+0x10/0x20<br /> [ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803)<br /> [ 1.448040] ---[ end trace 0000000000000000 ]---<br /> [ 1.448483] note: swapper/0[1] exited with preempt_count 1<br /> [ 1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b<br /> [ 1.449741] SMP: stopping secondary CPUs<br /> [ 1.450105] Kernel Offset: disabled<br /> [ 1.450419] CPU features: 0x000000,00080000,20002001,0400421b<br /> [ <br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/ivpu: Prevent recovery work from being queued during device removal<br /> <br /> Use disable_work_sync() instead of cancel_work_sync() in ivpu_dev_fini()<br /> to ensure that no new recovery work items can be queued after device<br /> removal has started. Previously, recovery work could be scheduled even<br /> after canceling existing work, potentially leading to use-after-free<br /> bugs if recovery accessed freed resources.<br /> <br /> Rename ivpu_pm_cancel_recovery() to ivpu_pm_disable_recovery() to better<br /> reflect its new behavior.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: xilinx: axienet: Add error handling for RX metadata pointer retrieval<br /> <br /> Add proper error checking for dmaengine_desc_get_metadata_ptr() which<br /> can return an error pointer and lead to potential crashes or undefined<br /> behaviour if the pointer retrieval fails.<br /> <br /> Properly handle the error by unmapping DMA buffer, freeing the skb and<br /> returning early to prevent further processing with invalid data.