lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 6 Jul 2021 10:44:55 +0800
From:   Hangbin Liu <haliu@...hat.com>
To:     Martynas Pumputis <m@...bda.lt>
Cc:     netdev@...r.kernel.org, stephen@...workplumber.org,
        dsahern@...il.com
Subject: Re: [PATCH iproute2] libbpf: fix attach of prog with multiple
 sections

On Mon, Jul 05, 2021 at 02:43:07PM +0200, Martynas Pumputis wrote:
> When BPF programs which consists of multiple executable sections via
> iproute2+libbpf (configured with LIBBPF_FORCE=on), we noticed that a
> wrong section can be attached to a device. E.g.:
> 
>     # tc qdisc replace dev lxc_health clsact
>     # tc filter replace dev lxc_health ingress prio 1 \
>         handle 1 bpf da obj bpf_lxc.o sec from-container
>     # tc filter show dev lxc_health ingress filter protocol all
>         pref 1 bpf chain 0 filter protocol all pref 1 bpf chain 0
>         handle 0x1 bpf_lxc.o:[__send_drop_notify] <-- WRONG SECTION
>         direct-action not_in_hw id 38 tag 7d891814eda6809e jited
> 
> After taking a closer look into load_bpf_object() in lib/bpf_libbpf.c,
> we noticed that the filter used in the program iterator does not check
> whether a program section name matches a requested section name
> (cfg->section). This can lead to a wrong prog FD being used to attach
> the program.
> 
> Fixes: 6d61a2b55799 ("lib: add libbpf support")
> Signed-off-by: Martynas Pumputis <m@...bda.lt>
> ---
>  lib/bpf_libbpf.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/bpf_libbpf.c b/lib/bpf_libbpf.c
> index d05737a4..f76b90d2 100644
> --- a/lib/bpf_libbpf.c
> +++ b/lib/bpf_libbpf.c
> @@ -267,10 +267,12 @@ static int load_bpf_object(struct bpf_cfg_in *cfg)
>  	}
>  
>  	bpf_object__for_each_program(p, obj) {
> +		bool prog_to_attach = !prog && cfg->section &&
> +			!strcmp(get_bpf_program__section_name(p), cfg->section);
> +
>  		/* Only load the programs that will either be subsequently
>  		 * attached or inserted into a tail call map */
> -		if (find_legacy_tail_calls(p, obj) < 0 && cfg->section &&
> -		    strcmp(get_bpf_program__section_name(p), cfg->section)) {
> +		if (find_legacy_tail_calls(p, obj) < 0 && !prog_to_attach) {
>  			ret = bpf_program__set_autoload(p, false);
>  			if (ret)
>  				return -EINVAL;
> @@ -279,7 +281,8 @@ static int load_bpf_object(struct bpf_cfg_in *cfg)
>  
>  		bpf_program__set_type(p, cfg->type);
>  		bpf_program__set_ifindex(p, cfg->ifindex);
> -		if (!prog)
> +
> +		if (prog_to_attach)
>  			prog = p;
>  	}
>  
> -- 
> 2.32.0
> 

Thanks for the fix.

Acked-by: Hangbin Liu <haliu@...hat.com>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ