netdev - Re: [PATCH net-next] tools: bpf: handle long path in jit disasm

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]

Message-ID: <1174FFEE-A6FF-4FC5-A6CF-249D99124441@intel.com>
Date:   Thu, 2 Nov 2017 21:19:44 +0000
From:   "Rustad, Mark D" <mark.d.rustad@...el.com>
To:     Prashant Bhole <bhole_prashant_q7@....ntt.co.jp>
CC:     "David S . Miller" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        "Daniel Borkmann" <daniel@...earbox.net>
Subject: Re: [PATCH net-next] tools: bpf: handle long path in jit disasm


> On Nov 2, 2017, at 1:09 AM, Prashant Bhole <bhole_prashant_q7@....ntt.co.jp> wrote:
> 
> Use PATH_MAX instead of hardcoded array size 256
> 
> Signed-off-by: Prashant Bhole <bhole_prashant_q7@....ntt.co.jp>
> ---
> tools/bpf/bpf_jit_disasm.c     | 3 ++-
> tools/bpf/bpftool/jit_disasm.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/bpf/bpf_jit_disasm.c b/tools/bpf/bpf_jit_disasm.c
> index 422d9abd666a..75bf526a0168 100644
> --- a/tools/bpf/bpf_jit_disasm.c
> +++ b/tools/bpf/bpf_jit_disasm.c
> @@ -27,6 +27,7 @@
> #include <sys/klog.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> +#include <limits.h>
> 
> #define CMD_ACTION_SIZE_BUFFER		10
> #define CMD_ACTION_READ_ALL		3
> @@ -51,7 +52,7 @@ static void get_exec_path(char *tpath, size_t size)
> static void get_asm_insns(uint8_t *image, size_t len, int opcodes)
> {
> 	int count, i, pc = 0;
> -	char tpath[256];
> +	char tpath[PATH_MAX];

Seems like such a nice thing, *but* PATH_MAX is 4096. Can things really tolerate 4k on the stack here?

> 	struct disassemble_info info;
> 	disassembler_ftype disassemble;
> 	bfd *bfdf;
> diff --git a/tools/bpf/bpftool/jit_disasm.c b/tools/bpf/bpftool/jit_disasm.c
> index 5937e134e408..1551d3918d4c 100644
> --- a/tools/bpf/bpftool/jit_disasm.c
> +++ b/tools/bpf/bpftool/jit_disasm.c
> @@ -21,6 +21,7 @@
> #include <dis-asm.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> +#include <limits.h>
> 
> #include "json_writer.h"
> #include "main.h"
> @@ -80,7 +81,7 @@ void disasm_print_insn(unsigned char *image, ssize_t len, int opcodes)
> 	disassembler_ftype disassemble;
> 	struct disassemble_info info;
> 	int count, i, pc = 0;
> -	char tpath[256];
> +	char tpath[PATH_MAX];

Same comment here.

> 	bfd *bfdf;
> 
> 	if (!len)

--
Mark Rustad, Networking Division, Intel Corporation


Download attachment "signature.asc" of type "application/pgp-signature" (842 bytes)