From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f66.google.com (mail-wm0-f66.google.com [74.125.82.66]) by dpdk.org (Postfix) with ESMTP id E8F531B287 for ; Mon, 30 Oct 2017 16:37:53 +0100 (CET) Received: by mail-wm0-f66.google.com with SMTP id y80so9892778wmd.0 for ; Mon, 30 Oct 2017 08:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=osAZuVUQV/C6Z5pGrT4yvxZecxq+UQrT/BsGcpYAm6U=; b=KJ0GF8AKLqw2FzlqvMgyKETsJiZnngUAMM7eSqbLVPVDYyNusG8lKUCUcSqVdqYzPr NwWUToHPBND5N3tAsNnd3WBKqmz3haPq4gPS6YU/bvBanOgRBm12fhWdiGLIBmPSKhSu P12qq6wKpWOMaRBunaOWmApfH5RAmDrjpcxMJjsB5sOk/a2yPDReMefez/mA/GGturBm l9lYs9Y4GjDzuupPVIS2mwe8joSdq8MdVMeXpZcOjgE69UgA5os2J6BjD21PH0/fuKgp BbWWyATgqTg2dfCFs+4Xix/abAfQgvRyDuJ0WkSHYCmGF2Sp7Gux3/aDA9lkVP90myd4 oGMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=osAZuVUQV/C6Z5pGrT4yvxZecxq+UQrT/BsGcpYAm6U=; b=nA+8MaMWMIuJtBozltVVTWuO3vCg7sq/4jSMYRt8mHU88YaSGDsK7DRIhWBYHNLXP/ 9/sx3OGv5LE7YZwitfhlDwJMs+1BtbEJd+WisBHLfxhE+izkLpKYoay5/KlseJZM41PS yRoi4mCUU3s24h54gVQHb5yKexPVuO0Ub7NDNJ7E865a4aH2QINSBjDnyeH0jV6DKny5 vURxX4078Wfd58czmKThdzawWikDEDAnAPy5GOCf5LhVNNu9wW68nIjInGCSblNSeZM9 fFKUgm9RO04fsNLRmGULAQcjGDkQWbF5QzYYTA/bpdcgND63qvErrWCOsrpqcoNn76nY OPUA== X-Gm-Message-State: AMCzsaWamc+BjlNprYEQgLc4rC6D+HHIQub9qzbspuPiPDWhep0pOi8H iDAWdL94/fr/SDp8DG8PhHc= X-Google-Smtp-Source: ABhQp+TMiERXhZuzy4QakAqACyurwOmk9lxd68yvUQIhNTnZ4Bp9+9RJYLIQgBwbV57fY+oi64FX+g== X-Received: by 10.28.48.150 with SMTP id w144mr3962522wmw.23.1509377873661; Mon, 30 Oct 2017 08:37:53 -0700 (PDT) Received: from localhost ([2a00:23c5:bef3:400:4a51:b7ff:fe0b:4749]) by smtp.gmail.com with ESMTPSA id b11sm13542660wrd.91.2017.10.30.08.37.52 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 30 Oct 2017 08:37:52 -0700 (PDT) From: luca.boccassi@gmail.com To: Patrick MacArthur Cc: Sergio Gonzalez Monroy , dpdk stable Date: Mon, 30 Oct 2017 15:34:44 +0000 Message-Id: <20171030153511.13322-41-luca.boccassi@gmail.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20171030153511.13322-1-luca.boccassi@gmail.com> References: <20171030153511.13322-1-luca.boccassi@gmail.com> Subject: [dpdk-stable] patch 'eal: copy raw strings taken from command line' has been queued to LTS release 16.11.4 X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 15:37:54 -0000 Hi, FYI, your patch has been queued to LTS release 16.11.4 Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. It will be pushed if I get no objections before 11/01/17. So please shout if anyone has objections. Thanks. Kind regards, Luca Boccassi --- >>From 4f267d69a21e9d7a55c67981087e0645ca021109 Mon Sep 17 00:00:00 2001 From: Patrick MacArthur Date: Fri, 4 Aug 2017 14:53:57 -0400 Subject: [PATCH] eal: copy raw strings taken from command line [ upstream commit e3f141879ef480c9e72e95d179c0879aed461406 ] Normally, command line argument strings are considered immutable, but SPDK [1] and urdma [2] construct argv arrays to pass to rte_eal_init(). These strings are allocated using malloc() and freed after DPDK initialization with free(). However, in the case of --file-prefix and --huge-dir, DPDK takes the pointer to these strings in argv directly. If a secondary process calls rte_eal_pci_probe() after rte_eal_init() returns, as is done by SPDK, this causes a use-after-free error because the strings have been freed by the calling code immediately after rte_eal_init() returns. This problem was observed when running SPDK example programs as a secondary process and causes the secondary processes to fail: Starting DPDK 16.11.1 initialization... [ DPDK EAL parameters: identify -c 4 --file-prefix=spdk3260 --base-virtaddr=0x1000000000 --proc-type=auto ] EAL: Detected 40 lcore(s) EAL: Auto-detected process type: SECONDARY EAL: Probing VFIO support... EAL: VFIO support initialized EAL: PCI device 0000:81:00.0 on NUMA socket 1 EAL: probe driver: 8086:953 spdk_nvme EAL: cannot connect to primary process! EAL: Error - exiting with code: 1 Cause: Requested device 0000:81:00.0 cannot be used Running strace shows that the file prefix has been zero'd out by the time that the secondary process attempts to probe the NVMe device. The use-after-free errors can be easily detected with valgrind: ==8489== Invalid read of size 1 ==8489== at 0x4C30D22: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==8489== by 0x58DB955: vfprintf (vfprintf.c:1637) ==8489== by 0x59A4685: __vsnprintf_chk (vsnprintf_chk.c:63) ==8489== by 0x59A45E7: __snprintf_chk (snprintf_chk.c:34) ==8489== by 0x1246AB: get_socket_path.constprop.0 (in /home/pmacarth/src/spdk/examples/nvme/identify/identify) ==8489== by 0x124B09: vfio_mp_sync_connect_to_primary (in /home/pmacarth/src/spdk/examples/nvme/identify/identify) ==8489== by 0x123BE4: vfio_get_group_fd.part.1 (in /home/pmacarth/src/spdk/examples/nvme/identify/identify) ==8489== by 0x124366: vfio_setup_device (in /home/pmacarth/src/spdk/examples/nvme/identify/identify) ==8489== by 0x126C8A: pci_vfio_map_resource (in /home/pmacarth/src/spdk/examples/nvme/identify/identify) ==8489== by 0x12B115: pci_probe_all_drivers.part.0 (in /home/pmacarth/src/spdk/examples/nvme/identify/identify) ==8489== by 0x12B596: rte_eal_pci_probe (in /home/pmacarth/src/spdk/examples/nvme/identify/identify) ==8489== by 0x11D5B5: spdk_pci_enumerate (pci.c:147) ==8489== Address 0x63f362e is 14 bytes inside a block of size 32 free'd ==8489== at 0x4C2ED5B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==8489== by 0x11E6FB: spdk_free_args (init.c:136) ==8489== by 0x11EBF5: spdk_env_init (init.c:309) ==8489== by 0x10D2AA: main (identify.c:976) ==8489== Block was alloc'd at ==8489== at 0x4C2DB2F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==8489== by 0x11E7D7: _sprintf_alloc (init.c:76) ==8489== by 0x11EA78: spdk_build_eal_cmdline (init.c:251) ==8489== by 0x11EA78: spdk_env_init (init.c:282) ==8489== by 0x10D2AA: main (identify.c:976) ==8489== Fix this by using strdup() to create separate memory buffers for these strings. Note that this patch will cause valgrind to report memory leaks of these buffers as there is nowhere to free them. Using static buffers is an option but would make these strings have a fixed maximum length whereas there is currently no limit defined by the API. [1] http://spdk.io [2] https://github.com/zrlio/urdma Fixes: af75078fece3 ("first public release") Signed-off-by: Patrick MacArthur Acked-by: Sergio Gonzalez Monroy --- lib/librte_eal/linuxapp/eal/eal.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/librte_eal/linuxapp/eal/eal.c b/lib/librte_eal/linuxapp/eal/eal.c index 2075282e2..59ed78823 100644 --- a/lib/librte_eal/linuxapp/eal/eal.c +++ b/lib/librte_eal/linuxapp/eal/eal.c @@ -570,11 +570,11 @@ eal_parse_args(int argc, char **argv) break; case OPT_HUGE_DIR_NUM: - internal_config.hugepage_dir = optarg; + internal_config.hugepage_dir = strdup(optarg); break; case OPT_FILE_PREFIX_NUM: - internal_config.hugefile_prefix = optarg; + internal_config.hugefile_prefix = strdup(optarg); break; case OPT_SOCKET_MEM_NUM: -- 2.11.0