On Sun, 2020-10-25 at 12:11 +0000, Luca Boccassi wrote: > On Sat, 24 Oct 2020 at 18:38, Adam D. Barratt <adam@adam-barratt.org.uk> wrote: > > On Fri, 2020-10-16 at 17:05 +0000, Adam D Barratt wrote: > > > Package: dpdk > > > Version: 18.11.10-1~deb10u1 > > > > > > Explanation: new upstream stable release; fix remote code execution > > > issue [CVE-2020-14374], TOCTOU issues [CVE-2020-14375], buffer > > > overflow [CVE-2020-14376], buffer over read [CVE-2020-14377] and > > > integer underflow [CVE-2020-14377] > > > > Unfortunately, this FTBFS on armhf (in three attempts across two > > different buildds): > > > > --- start log extract --- > > > > FAILED: drivers/a715181@@tmp_rte_pmd_i40e@sta/net_i40e_i40e_rxtx_vec_neon.c.o > > cc -Idrivers/a715181@@tmp_rte_pmd_i40e@sta -Idrivers -I../drivers -Idrivers/net/i40e -I../drivers/net/i40e -Idrivers/net/i40e/base -I../drivers/net/i40e/base -Ilib/librte_ethdev -I../lib/librte_ethdev -I. -I../ -Iconfig -I../config -Ilib/librte_eal/common -I../lib/librte_eal/common -Ilib/librte_eal/common/include -I../lib/librte_eal/common/include -Ilib/librte_eal/common/include/arch/arm -I../lib/librte_eal/common/include/arch/arm -I../lib/librte_eal/linuxapp/eal/include -Ilib/librte_eal/linuxapp/eal/../../../librte_compat -I../lib/librte_eal/linuxapp/eal/../../../librte_compat -Ilib/librte_eal -I../lib/librte_eal -Ilib/librte_kvargs/../librte_eal/common/include -I../lib/librte_kvargs/../librte_eal/common/include -Ilib/librte_kvargs -I../lib/librte_kvargs -Ilib/librte_compat -I../lib/librte_compat -Ilib/librte_net -I../lib/librte_net -Ilib/librte_mbuf -I../lib/librte_mbuf -Ilib/librte_mempool -I../lib/librte_mempool -Ilib/librte_ring -I../lib/librte_ring -Ilib/librte_cmdline/../librte_eal/common/include -I../lib/librte_cmdline/../librte_eal/common/include -Ilib/librte_cmdline -I../lib/librte_cmdline -Idrivers/bus/pci -I../drivers/bus/pci -I../drivers/bus/pci/linux -Ilib/librte_pci -I../lib/librte_pci -Idrivers/bus/vdev -I../drivers/bus/vdev -Ilib/librte_hash -I../lib/librte_hash -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -include rte_config.h -Wsign-compare -Wcast-qual -Wno-pointer-to-int-cast -D_GNU_SOURCE -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -march=armv7-a -mfpu=neon -Wno-format-truncation -DPF_DRIVER -DVF_DRIVER -DINTEGRATED_VF -DX722_A0_SUPPORT -DALLOW_EXPERIMENTAL_API -MD -MQ 'drivers/a715181@@tmp_rte_pmd_i40e@sta/net_i40e_i40e_rxtx_vec_neon.c.o' -MF 'drivers/a715181@@tmp_rte_pmd_i40e@sta/net_i40e_i40e_rxtx_vec_neon.c.o.d' -o 'drivers/a715181@@tmp_rte_pmd_i40e@sta/net_i40e_i40e_rxtx_vec_neon.c.o' -c ../drivers/net/i40e/i40e_rxtx_vec_neon.c > > ../drivers/net/i40e/i40e_rxtx_vec_neon.c: In function ‘desc_to_olflags_v’: > > ../drivers/net/i40e/i40e_rxtx_vec_neon.c:142:31: warning: implicit declaration of function ‘vqtbl1q_u8’; did you mean ‘vtbl1_u8’? [-Wimplicit-function-declaration] > > vlan0 = vreinterpretq_u32_u8(vqtbl1q_u8(vlan_flags, > > ^~~~~~~~~~ > > vtbl1_u8 > > ../drivers/net/i40e/i40e_rxtx_vec_neon.c:142:31: error: incompatible type for argument 1 of ‘vreinterpretq_u32_u8’ > > vlan0 = vreinterpretq_u32_u8(vqtbl1q_u8(vlan_flags, > > ^~~~~~~~~~~~~~~~~~~~~~ > > vreinterpretq_u8_u32(vlan1))); > > [...] > > ../drivers/net/i40e/i40e_rxtx_vec_neon.c: In function ‘_recv_raw_pkts_vec’: > > ../drivers/net/i40e/i40e_rxtx_vec_neon.c:320:11: error: incompatible types when assigning to type ‘uint8x16_t’ from type ‘int’ > > pkt_mb4 = vqtbl1q_u8(vreinterpretq_u8_u64(descs[3]), shuf_msk); > > ^ > > ../drivers/net/i40e/i40e_rxtx_vec_neon.c:321:11: error: incompatible types when assigning to type ‘uint8x16_t’ from type ‘int’ > > pkt_mb3 = vqtbl1q_u8(vreinterpretq_u8_u64(descs[2]), shuf_msk); > > ^ > > ../drivers/net/i40e/i40e_rxtx_vec_neon.c:351:11: error: incompatible types when assigning to type ‘uint8x16_t’ from type ‘int’ > > pkt_mb2 = vqtbl1q_u8(vreinterpretq_u8_u64(descs[1]), shuf_msk); > > ^ > > ../drivers/net/i40e/i40e_rxtx_vec_neon.c:352:11: error: incompatible types when assigning to type ‘uint8x16_t’ from type ‘int’ > > pkt_mb1 = vqtbl1q_u8(vreinterpretq_u8_u64(descs[0]), shuf_msk); > > ^ > > ../drivers/net/i40e/i40e_rxtx_vec_neon.c:383:13: error: incompatible types when assigning to type ‘uint8x16_t’ from type ‘int’ > > eop_bits = vqtbl1q_u8(eop_bits, eop_shuf_mask); > > > > ^ > > > > --- end log extract --- > > > > Regards, > > > > Adam > > Mh that looks familiar, I thought it was already fixed. I'll have a > look on Monday morning, and also see why the CI missed it. > > Kind regards, > Luca Boccassi I found the issue, and I have a patch ready (a mainline commit was mistakenly not tagged for backport). Also found that the armv7 CI was disabled due to infra issues - I'll fix that too. In terms of process, how do I proceed? A deb10u2 upload to stable? Do I need to create a new bug? -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part