[ovs-dev] [PATCH v3 1/2] tun_metadata: Fix coredump caused by use-after-free bug

William Tu u9012063 at gmail.com
Fri Apr 10 21:54:09 UTC 2020


On Thu, Apr 09, 2020 at 11:37:38AM -0700, Yifeng Sun wrote:
> Tun_metadata can be referened by flow and frozen_state at the same
> time. When ovs-vswitchd handles TLV table mod message, the involved
> tun_metadata gets freed. The call trace to free tun_metadata is
> shown as below:
> 
> ofproto_run
> - handle_openflow
>   - handle_single_part_openflow
>     - handle_tlv_table_mod
>       - tun_metadata_table_mod
>         - tun_metadata_postpone_free
> 
> Unfortunately, this tun_metadata can be still used by some frozen_state,
> and later on when frozen_state tries to access its tun_metadata table,
> ovs-vswitchd crashes. The call trace to access tun_metadata from
> frozen_state is shown as below:
> 
> udpif_upcall_handler
> - recv_upcalls
>   - process_upcall
>     - frozen_metadata_to_flow
> 
> It is unsafe for frozen_state to reference tun_table because tun_table
> is protected by RCU while the lifecycle of frozen_state can span several
> RCU quiesce states. Current code violates OVS's RCU protection mechanism.
> 
> This patch fixes it by simply stopping frozen_state from referencing
> tun_table. If frozen_state needs tun_table, the latest valid tun_table
> can be found through ofproto_get_tun_tab() efficiently.
> 
> A previous commit seems fixing the samiliar issue:
> 254878c18874f6 (ofproto-dpif-xlate: Fix segmentation fault caused by tun_table)
> 
> VMware-BZ: #2526222
> Signed-off-by: Yifeng Sun <pkusunyifeng at gmail.com>
> ---
Applied, thanks
William


More information about the dev mailing list