Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dpaa2-ptp: Fix refcount leak in dpaa2_ptp_probe<br /> <br /> This node pointer is returned by of_find_compatible_node() with<br /> refcount incremented. Calling of_node_put() to aovid the refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> IB/rdmavt: add lock to call to rvt_error_qp to prevent a race condition<br /> <br /> The documentation of the function rvt_error_qp says both r_lock and s_lock<br /> need to be held when calling that function. It also asserts using lockdep<br /> that both of those locks are held. However, the commit I referenced in<br /> Fixes accidentally makes the call to rvt_error_qp in rvt_ruc_loopback no<br /> longer covered by r_lock. This results in the lockdep assertion failing<br /> and also possibly in a race condition.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arch/arm64: Fix topology initialization for core scheduling<br /> <br /> Arm64 systems rely on store_cpu_topology() to call update_siblings_masks()<br /> to transfer the toplogy to the various cpu masks. This needs to be done<br /> before the call to notify_cpu_starting() which tells the scheduler about<br /> each cpu found, otherwise the core scheduling data structures are setup<br /> in a way that does not match the actual topology.<br /> <br /> With smt_mask not setup correctly we bail on `cpumask_weight(smt_mask) == 1`<br /> for !leaders in:<br /> <br /> notify_cpu_starting()<br /> cpuhp_invoke_callback_range()<br /> sched_cpu_starting()<br /> sched_core_cpu_starting()<br /> <br /> which leads to rq-&gt;core not being correctly set for !leader-rq&amp;#39;s.<br /> <br /> Without this change stress-ng (which enables core scheduling in its prctl<br /> tests in newer versions -- i.e. with PR_SCHED_CORE support) causes a warning<br /> and then a crash (trimmed for legibility):<br /> <br /> [ 1853.805168] ------------[ cut here ]------------<br /> [ 1853.809784] task_rq(b)-&gt;core != rq-&gt;core<br /> [ 1853.809792] WARNING: CPU: 117 PID: 0 at kernel/sched/fair.c:11102 cfs_prio_less+0x1b4/0x1c4<br /> ...<br /> [ 1854.015210] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010<br /> ...<br /> [ 1854.231256] Call trace:<br /> [ 1854.233689] pick_next_task+0x3dc/0x81c<br /> [ 1854.237512] __schedule+0x10c/0x4cc<br /> [ 1854.240988] schedule_idle+0x34/0x54

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/imx: Fix memory leak in imx_pd_connector_get_modes<br /> <br /> Avoid leaking the display mode variable if of_get_drm_display_mode<br /> fails.<br /> <br /> Addresses-Coverity-ID: 1443943 ("Resource leak")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ipv4: fix route with nexthop object delete warning<br /> <br /> FRR folks have hit a kernel warning[1] while deleting routes[2] which is<br /> caused by trying to delete a route pointing to a nexthop id without<br /> specifying nhid but matching on an interface. That is, a route is found<br /> but we hit a warning while matching it. The warning is from<br /> fib_info_nh() in include/net/nexthop.h because we run it on a fib_info<br /> with nexthop object. The call chain is:<br /> inet_rtm_delroute -&gt; fib_table_delete -&gt; fib_nh_match (called with a<br /> nexthop fib_info and also with fc_oif set thus calling fib_info_nh on<br /> the fib_info and triggering the warning). The fix is to not do any<br /> matching in that branch if the fi has a nexthop object because those are<br /> managed separately. I.e. we should match when deleting without nh spec and<br /> should fail when deleting a nexthop route with old-style nh spec because<br /> nexthop objects are managed separately, e.g.:<br /> $ ip r show 1.2.3.4/32<br /> 1.2.3.4 nhid 12 via 192.168.11.2 dev dummy0<br /> <br /> $ ip r del 1.2.3.4/32<br /> $ ip r del 1.2.3.4/32 nhid 12<br /> <br /> <br /> $ ip r del 1.2.3.4/32 dev dummy0<br /> <br /> <br /> [1]<br /> [ 523.462226] ------------[ cut here ]------------<br /> [ 523.462230] WARNING: CPU: 14 PID: 22893 at include/net/nexthop.h:468 fib_nh_match+0x210/0x460<br /> [ 523.462236] Modules linked in: dummy rpcsec_gss_krb5 xt_socket nf_socket_ipv4 nf_socket_ipv6 ip6table_raw iptable_raw bpf_preload xt_statistic ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs xt_mark nf_tables xt_nat veth nf_conntrack_netlink nfnetlink xt_addrtype br_netfilter overlay dm_crypt nfsv3 nfs fscache netfs vhost_net vhost vhost_iotlb tap tun xt_CHECKSUM xt_MASQUERADE xt_conntrack 8021q garp mrp ipt_REJECT nf_reject_ipv4 ip6table_mangle ip6table_nat iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bridge stp llc rfcomm snd_seq_dummy snd_hrtimer rpcrdma rdma_cm iw_cm ib_cm ib_core ip6table_filter xt_comment ip6_tables vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) qrtr bnep binfmt_misc xfs vfat fat squashfs loop nvidia_drm(POE) nvidia_modeset(POE) nvidia_uvm(POE) nvidia(POE) intel_rapl_msr intel_rapl_common snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi btusb btrtl iwlmvm uvcvideo btbcm snd_hda_intel edac_mce_amd<br /> [ 523.462274] videobuf2_vmalloc videobuf2_memops btintel snd_intel_dspcfg videobuf2_v4l2 snd_intel_sdw_acpi bluetooth snd_usb_audio snd_hda_codec mac80211 snd_usbmidi_lib joydev snd_hda_core videobuf2_common kvm_amd snd_rawmidi snd_hwdep snd_seq videodev ccp snd_seq_device libarc4 ecdh_generic mc snd_pcm kvm iwlwifi snd_timer drm_kms_helper snd cfg80211 cec soundcore irqbypass rapl wmi_bmof i2c_piix4 rfkill k10temp pcspkr acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc drm zram ip_tables crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel nvme sp5100_tco r8169 nvme_core wmi ipmi_devintf ipmi_msghandler fuse<br /> [ 523.462300] CPU: 14 PID: 22893 Comm: ip Tainted: P OE 5.16.18-200.fc35.x86_64 #1<br /> [ 523.462302] Hardware name: Micro-Star International Co., Ltd. MS-7C37/MPG X570 GAMING EDGE WIFI (MS-7C37), BIOS 1.C0 10/29/2020<br /> [ 523.462303] RIP: 0010:fib_nh_match+0x210/0x460<br /> [ 523.462304] Code: 7c 24 20 48 8b b5 90 00 00 00 e8 bb ee f4 ff 48 8b 7c 24 20 41 89 c4 e8 ee eb f4 ff 45 85 e4 0f 85 2e fe ff ff e9 4c ff ff ff 0b e9 17 ff ff ff 3c 0a 0f 85 61 fe ff ff 48 8b b5 98 00 00 00<br /> [ 523.462306] RSP: 0018:ffffaa53d4d87928 EFLAGS: 00010286<br /> [ 523.462307] RAX: 0000000000000000 RBX: ffffaa53d4d87a90 RCX: ffffaa53d4d87bb0<br /> [ 523.462308] RDX: ffff9e3d2ee6be80 RSI: ffffaa53d4d87a90 RDI: ffffffff920ed380<br /> [ 523.462309] RBP: ffff9e3d2ee6be80 R08: 0000000000000064 R09: 0000000000000000<br /> [ 523.462310] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000031<br /> [ 523.462310] R13: 0000000000000020 R14: 0000000000000000 R15: ffff9e3d331054e0<br /> [ 523.462311] FS: 00007f2455<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> skbuff: fix coalescing for page_pool fragment recycling<br /> <br /> Fix a use-after-free when using page_pool with page fragments. We<br /> encountered this problem during normal RX in the hns3 driver:<br /> <br /> (1) Initially we have three descriptors in the RX queue. The first one<br /> allocates PAGE1 through page_pool, and the other two allocate one<br /> half of PAGE2 each. Page references look like this:<br /> <br /> RX_BD1 _______ PAGE1<br /> RX_BD2 _______ PAGE2<br /> RX_BD3 _________/<br /> <br /> (2) Handle RX on the first descriptor. Allocate SKB1, eventually added<br /> to the receive queue by tcp_queue_rcv().<br /> <br /> (3) Handle RX on the second descriptor. Allocate SKB2 and pass it to<br /> netif_receive_skb():<br /> <br /> netif_receive_skb(SKB2)<br /> ip_rcv(SKB2)<br /> SKB3 = skb_clone(SKB2)<br /> <br /> SKB2 and SKB3 share a reference to PAGE2 through<br /> skb_shinfo()-&gt;dataref. The other ref to PAGE2 is still held by<br /> RX_BD3:<br /> <br /> SKB2 ---+- PAGE2<br /> SKB3 __/ /<br /> RX_BD3 _________/<br /> <br /> (3b) Now while handling TCP, coalesce SKB3 with SKB1:<br /> <br /> tcp_v4_rcv(SKB3)<br /> tcp_try_coalesce(to=SKB1, from=SKB3) // succeeds<br /> kfree_skb_partial(SKB3)<br /> skb_release_data(SKB3) // drops one dataref<br /> <br /> SKB1 _____ PAGE1<br /> \____<br /> SKB2 _____ PAGE2<br /> /<br /> RX_BD3 _________/<br /> <br /> In skb_try_coalesce(), __skb_frag_ref() takes a page reference to<br /> PAGE2, where it should instead have increased the page_pool frag<br /> reference, pp_frag_count. Without coalescing, when releasing both<br /> SKB2 and SKB3, a single reference to PAGE2 would be dropped. Now<br /> when releasing SKB1 and SKB2, two references to PAGE2 will be<br /> dropped, resulting in underflow.<br /> <br /> (3c) Drop SKB2:<br /> <br /> af_packet_rcv(SKB2)<br /> consume_skb(SKB2)<br /> skb_release_data(SKB2) // drops second dataref<br /> page_pool_return_skb_page(PAGE2) // drops one pp_frag_count<br /> <br /> SKB1 _____ PAGE1<br /> \____<br /> PAGE2<br /> /<br /> RX_BD3 _________/<br /> <br /> (4) Userspace calls recvmsg()<br /> Copies SKB1 and releases it. Since SKB3 was coalesced with SKB1, we<br /> release the SKB3 page as well:<br /> <br /> tcp_eat_recv_skb(SKB1)<br /> skb_release_data(SKB1)<br /> page_pool_return_skb_page(PAGE1)<br /> page_pool_return_skb_page(PAGE2) // drops second pp_frag_count<br /> <br /> (5) PAGE2 is freed, but the third RX descriptor was still using it!<br /> In our case this causes IOMMU faults, but it would silently corrupt<br /> memory if the IOMMU was disabled.<br /> <br /> Change the logic that checks whether pp_recycle SKBs can be coalesced.<br /> We still reject differing pp_recycle between &amp;#39;from&amp;#39; and &amp;#39;to&amp;#39; SKBs, but<br /> in order to avoid the situation described above, we also reject<br /> coalescing when both &amp;#39;from&amp;#39; and &amp;#39;to&amp;#39; are pp_recycled and &amp;#39;from&amp;#39; is<br /> cloned.<br /> <br /> The new logic allows coalescing a cloned pp_recycle SKB into a page<br /> refcounted one, because in this case the release (4) will drop the right<br /> reference, the one taken by skb_try_coalesce().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/tls: fix slab-out-of-bounds bug in decrypt_internal<br /> <br /> The memory size of tls_ctx-&gt;rx.iv for AES128-CCM is 12 setting in<br /> tls_set_sw_offload(). The return value of crypto_aead_ivsize()<br /> for "ccm(aes)" is 16. So memcpy() require 16 bytes from 12 bytes<br /> memory space will trigger slab-out-of-bounds bug as following:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in decrypt_internal+0x385/0xc40 [tls]<br /> Read of size 16 at addr ffff888114e84e60 by task tls/10911<br /> <br /> Call Trace:<br /> <br /> dump_stack_lvl+0x34/0x44<br /> print_report.cold+0x5e/0x5db<br /> ? decrypt_internal+0x385/0xc40 [tls]<br /> kasan_report+0xab/0x120<br /> ? decrypt_internal+0x385/0xc40 [tls]<br /> kasan_check_range+0xf9/0x1e0<br /> memcpy+0x20/0x60<br /> decrypt_internal+0x385/0xc40 [tls]<br /> ? tls_get_rec+0x2e0/0x2e0 [tls]<br /> ? process_rx_list+0x1a5/0x420 [tls]<br /> ? tls_setup_from_iter.constprop.0+0x2e0/0x2e0 [tls]<br /> decrypt_skb_update+0x9d/0x400 [tls]<br /> tls_sw_recvmsg+0x3c8/0xb50 [tls]<br /> <br /> Allocated by task 10911:<br /> kasan_save_stack+0x1e/0x40<br /> __kasan_kmalloc+0x81/0xa0<br /> tls_set_sw_offload+0x2eb/0xa20 [tls]<br /> tls_setsockopt+0x68c/0x700 [tls]<br /> __sys_setsockopt+0xfe/0x1b0<br /> <br /> Replace the crypto_aead_ivsize() with prot-&gt;iv_size + prot-&gt;salt_size<br /> when memcpy() iv value in TLS_1_3_VERSION scenario.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: zorro7xx: Fix a resource leak in zorro7xx_remove_one()<br /> <br /> The error handling path of the probe releases a resource that is not freed<br /> in the remove function. In some cases, a ioremap() must be undone.<br /> <br /> Add the missing iounmap() call in the remove function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmmremap.c: avoid pointless invalidate_range_start/end on mremap(old_size=0)<br /> <br /> If an mremap() syscall with old_size=0 ends up in move_page_tables(), it<br /> will call invalidate_range_start()/invalidate_range_end() unnecessarily,<br /> i.e. with an empty range.<br /> <br /> This causes a WARN in KVM&amp;#39;s mmu_notifier. In the past, empty ranges<br /> have been diagnosed to be off-by-one bugs, hence the WARNing. Given the<br /> low (so far) number of unique reports, the benefits of detecting more<br /> buggy callers seem to outweigh the cost of having to fix cases such as<br /> this one, where userspace is doing something silly. In this particular<br /> case, an early return from move_page_tables() is enough to fix the<br /> issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: zoned: traverse devices under chunk_mutex in btrfs_can_activate_zone<br /> <br /> btrfs_can_activate_zone() can be called with the device_list_mutex already<br /> held, which will lead to a deadlock:<br /> <br /> insert_dev_extents() // Takes device_list_mutex<br /> `-&gt; insert_dev_extent()<br /> `-&gt; btrfs_insert_empty_item()<br /> `-&gt; btrfs_insert_empty_items()<br /> `-&gt; btrfs_search_slot()<br /> `-&gt; btrfs_cow_block()<br /> `-&gt; __btrfs_cow_block()<br /> `-&gt; btrfs_alloc_tree_block()<br /> `-&gt; btrfs_reserve_extent()<br /> `-&gt; find_free_extent()<br /> `-&gt; find_free_extent_update_loop()<br /> `-&gt; can_allocate_chunk()<br /> `-&gt; btrfs_can_activate_zone() // Takes device_list_mutex again<br /> <br /> Instead of using the RCU on fs_devices-&gt;device_list we<br /> can use fs_devices-&gt;alloc_list, protected by the chunk_mutex to traverse<br /> the list of active devices.<br /> <br /> We are in the chunk allocation thread. The newer chunk allocation<br /> happens from the devices in the fs_device-&gt;alloc_list protected by the<br /> chunk_mutex.<br /> <br /> btrfs_create_chunk()<br /> lockdep_assert_held(&amp;info-&gt;chunk_mutex);<br /> gather_device_info<br /> list_for_each_entry(device, &amp;fs_devices-&gt;alloc_list, dev_alloc_list)<br /> <br /> Also, a device that reappears after the mount won&amp;#39;t join the alloc_list<br /> yet and, it will be in the dev_list, which we don&amp;#39;t want to consider in<br /> the context of the chunk alloc.<br /> <br /> [15.166572] WARNING: possible recursive locking detected<br /> [15.167117] 5.17.0-rc6-dennis #79 Not tainted<br /> [15.167487] --------------------------------------------<br /> [15.167733] kworker/u8:3/146 is trying to acquire lock:<br /> [15.167733] ffff888102962ee0 (&amp;fs_devs-&gt;device_list_mutex){+.+.}-{3:3}, at: find_free_extent+0x15a/0x14f0 [btrfs]<br /> [15.167733]<br /> [15.167733] but task is already holding lock:<br /> [15.167733] ffff888102962ee0 (&amp;fs_devs-&gt;device_list_mutex){+.+.}-{3:3}, at: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs]<br /> [15.167733]<br /> [15.167733] other info that might help us debug this:<br /> [15.167733] Possible unsafe locking scenario:<br /> [15.167733]<br /> [15.171834] CPU0<br /> [15.171834] ----<br /> [15.171834] lock(&amp;fs_devs-&gt;device_list_mutex);<br /> [15.171834] lock(&amp;fs_devs-&gt;device_list_mutex);<br /> [15.171834]<br /> [15.171834] *** DEADLOCK ***<br /> [15.171834]<br /> [15.171834] May be due to missing lock nesting notation<br /> [15.171834]<br /> [15.171834] 5 locks held by kworker/u8:3/146:<br /> [15.171834] #0: ffff888100050938 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x1c3/0x5a0<br /> [15.171834] #1: ffffc9000067be80 ((work_completion)(&amp;fs_info-&gt;async_data_reclaim_work)){+.+.}-{0:0}, at: process_one_work+0x1c3/0x5a0<br /> [15.176244] #2: ffff88810521e620 (sb_internal){.+.+}-{0:0}, at: flush_space+0x335/0x600 [btrfs]<br /> [15.176244] #3: ffff888102962ee0 (&amp;fs_devs-&gt;device_list_mutex){+.+.}-{3:3}, at: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs]<br /> [15.176244] #4: ffff8881152e4b78 (btrfs-dev-00){++++}-{3:3}, at: __btrfs_tree_lock+0x27/0x130 [btrfs]<br /> [15.179641]<br /> [15.179641] stack backtrace:<br /> [15.179641] CPU: 1 PID: 146 Comm: kworker/u8:3 Not tainted 5.17.0-rc6-dennis #79<br /> [15.179641] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1.fc35 04/01/2014<br /> [15.179641] Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs]<br /> [15.179641] Call Trace:<br /> [15.179641] <br /> [15.179641] dump_stack_lvl+0x45/0x59<br /> [15.179641] __lock_acquire.cold+0x217/0x2b2<br /> [15.179641] lock_acquire+0xbf/0x2b0<br /> [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs]<br /> [15.183838] __mutex_lock+0x8e/0x970<br /> [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs]<br /> [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs]<br /> [15.183838] ? lock_is_held_type+0xd7/0x130<br /> [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs]<br /> [15.183838] find_free_extent+0x15a/0x14f0 [btrfs]<br /> [15.183838] ? _raw_spin_unlock+0x24/0x40<br /> [15.183838] ? btrfs_get_alloc_profile+0x106/0x230 [btrfs]<br /> [15.187601] btrfs_reserve_extent+0x131/0x260 [btrfs]<br /> [15.<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/mempolicy: fix mpol_new leak in shared_policy_replace<br /> <br /> If mpol_new is allocated but not used in restart loop, mpol_new will be<br /> freed via mpol_put before returning to the caller. But refcnt is not<br /> initialized yet, so mpol_put could not do the right things and might<br /> leak the unused mpol_new. This would happen if mempolicy was updated on<br /> the shared shmem file while the sp-&gt;lock has been dropped during the<br /> memory allocation.<br /> <br /> This issue could be triggered easily with the below code snippet if<br /> there are many processes doing the below work at the same time:<br /> <br /> shmid = shmget((key_t)5566, 1024 * PAGE_SIZE, 0666|IPC_CREAT);<br /> shm = shmat(shmid, 0, 0);<br /> loop many times {<br /> mbind(shm, 1024 * PAGE_SIZE, MPOL_LOCAL, mask, maxnode, 0);<br /> mbind(shm + 128 * PAGE_SIZE, 128 * PAGE_SIZE, MPOL_DEFAULT, mask,<br /> maxnode, 0);<br /> }

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> highmem: fix checks in __kmap_local_sched_{in,out}<br /> <br /> When CONFIG_DEBUG_KMAP_LOCAL is enabled __kmap_local_sched_{in,out} check<br /> that even slots in the tsk-&gt;kmap_ctrl.pteval are unmapped. The slots are<br /> initialized with 0 value, but the check is done with pte_none. 0 pte<br /> however does not necessarily mean that pte_none will return true. e.g.<br /> on xtensa it returns false, resulting in the following runtime warnings:<br /> <br /> WARNING: CPU: 0 PID: 101 at mm/highmem.c:627 __kmap_local_sched_out+0x51/0x108<br /> CPU: 0 PID: 101 Comm: touch Not tainted 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13<br /> Call Trace:<br /> dump_stack+0xc/0x40<br /> __warn+0x8f/0x174<br /> warn_slowpath_fmt+0x48/0xac<br /> __kmap_local_sched_out+0x51/0x108<br /> __schedule+0x71a/0x9c4<br /> preempt_schedule_irq+0xa0/0xe0<br /> common_exception_return+0x5c/0x93<br /> do_wp_page+0x30e/0x330<br /> handle_mm_fault+0xa70/0xc3c<br /> do_page_fault+0x1d8/0x3c4<br /> common_exception+0x7f/0x7f<br /> <br /> WARNING: CPU: 0 PID: 101 at mm/highmem.c:664 __kmap_local_sched_in+0x50/0xe0<br /> CPU: 0 PID: 101 Comm: touch Tainted: G W 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13<br /> Call Trace:<br /> dump_stack+0xc/0x40<br /> __warn+0x8f/0x174<br /> warn_slowpath_fmt+0x48/0xac<br /> __kmap_local_sched_in+0x50/0xe0<br /> finish_task_switch$isra$0+0x1ce/0x2f8<br /> __schedule+0x86e/0x9c4<br /> preempt_schedule_irq+0xa0/0xe0<br /> common_exception_return+0x5c/0x93<br /> do_wp_page+0x30e/0x330<br /> handle_mm_fault+0xa70/0xc3c<br /> do_page_fault+0x1d8/0x3c4<br /> common_exception+0x7f/0x7f<br /> <br /> Fix it by replacing !pte_none(pteval) with pte_val(pteval) != 0.