[Kernel-packages] [Bug 1876982] Re: tunnels over IPv6 are unencrypted when using IPsec
** Changed in: linux (Ubuntu Bionic) Status: In Progress => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1876982 Title: tunnels over IPv6 are unencrypted when using IPsec Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Fix Released Status in linux source package in Bionic: Fix Released Bug description: [Impact] When tunnels are configured over IPv6 using a xfrm policy, it's ignored. That means data will be unencrypted when it shouldn't. [Test case] Launch a VM with the given kernel and monitor its network link on the host with: tcpdump -n -i virbr0 ip6 and port 4789 In the guest, set up a tunnel using an IPv6 address: ip link add type vxlan id 5 remote fd00:cafe::2 dstport 4789 When setting the link up, observe packets being output on the host side: ip link set vxlan0 up Set the link down, and add a xfrm policy to block output to that given IPv6 address: ip link set vxlan0 down ip xfrm policy add dst fd00:cafe::2 dir out action block Check that using ping won't work with Operation not permitted: ping6 fd00:cafe::2 connect: Operation not permitted Set the vxlan link up and watch that no packets appear on tcpdump: ip link set vxlan0 up [Regression potential] Tunnels like VXLAN, GENEVE, etc, will stop to send. The test has shown that it still sends at least when no xfrm policy is configured. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1876982/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1876982] Re: tunnels over IPv6 are unencrypted when using IPsec
This bug was fixed in the package linux - 4.4.0-184.214
---
linux (4.4.0-184.214) xenial; urgency=medium
* CVE-2020-0543
- SAUCE: x86/cpu: Add a steppings field to struct x86_cpu_id
- SAUCE: x86/cpu: Add 'table' argument to cpu_matches()
- SAUCE: x86/speculation: Add Special Register Buffer Data Sampling (SRBDS)
mitigation
- SAUCE: x86/speculation: Add SRBDS vulnerability and mitigation
documentation
- SAUCE: x86/speculation: Add Ivy Bridge to affected list
linux (4.4.0-181.211) xenial; urgency=medium
* xenial/linux: 4.4.0-181.211 -proposed tracker (LP: #1881170)
* CVE-2020-12769
- spi: spi-dw: Add lock protect dw_spi rx/tx to prevent concurrent calls
* I2C bus on Dell Edge Gateway stops working after upgrading to
Ubuntu-4.4.0-180.210 (LP: #1881124)
- SAUCE: Revert: Revert "ACPI / LPSS: allow to use specific PM domain during
->probe()"
linux (4.4.0-180.210) xenial; urgency=medium
* xenial/linux: 4.4.0-180.210 -proposed tracker (LP: #1878873)
* Xenial update: 4.4.223 upstream stable release (LP: #1878232)
- mwifiex: fix PCIe register information for 8997 chipset
- drm/qxl: qxl_release use after free
- drm/qxl: qxl_release leak in qxl_draw_dirty_fb()
- staging: rtl8192u: Fix crash due to pointers being "confusing"
- usb: gadget: f_acm: Fix configfs attr name
- usb: gadged: pch_udc: get rid of redundant assignments
- usb: gadget: pch_udc: reorder spin_[un]lock to avoid deadlock
- usb: gadget: udc: core: don't starve DMA resources
- MIPS: Fix macro typo
- MIPS: ptrace: Drop cp0_tcstatus from regoffset_table[]
- MIPS: BMIPS: Fix PRID_IMP_BMIPS5000 masking for BMIPS5200
- MIPS: smp-cps: Stop printing EJTAG exceptions to UART
- MIPS: scall: Handle seccomp filters which redirect syscalls
- MIPS: BMIPS: BMIPS5000 has I cache filing from D cache
- MIPS: BMIPS: Clear MIPS_CACHE_ALIASES earlier
- MIPS: BMIPS: local_r4k___flush_cache_all needs to blast S-cache
- MIPS: BMIPS: Pretty print BMIPS5200 processor name
- MIPS: Fix HTW config on XPA kernel without LPA enabled
- MIPS: BMIPS: Adjust mips-hpt-frequency for BCM7435
- MIPS: math-emu: Fix BC1{EQ,NE}Z emulation
- MIPS: Fix BC1{EQ,NE}Z return offset calculation
- MIPS: perf: Fix I6400 event numbers
- MIPS: KVM: Fix translation of MFC0 ErrCtl
- MIPS: SMP: Update cpu_foreign_map on CPU disable
- MIPS: c-r4k: Fix protected_writeback_scache_line for EVA
- MIPS: Octeon: Off by one in octeon_irq_gpio_map()
- bpf, mips: fix off-by-one in ctx offset allocation
- MIPS: RM7000: Double locking bug in rm7k_tc_disable()
- MIPS: Define AT_VECTOR_SIZE_ARCH for ARCH_DLINFO
- mips/panic: replace smp_send_stop() with kdump friendly version in panic
path
- ARM: dts: armadillo800eva Correct extal1 frequency to 24 MHz
- ARM: imx: select SRC for i.MX7
- ARM: dts: kirkwood: gpio pin fixes for linkstation ls-wxl/wsxl
- ARM: dts: kirkwood: gpio pin fixes for linkstation ls-wvl/vl
- ARM: dts: kirkwood: gpio-leds fixes for linkstation ls-wxl/wsxl
- ARM: dts: kirkwood: gpio-leds fixes for linkstation ls-wvl/vl
- ARM: dts: orion5x: gpio pin fixes for linkstation lswtgl
- ARM: dts: orion5x: fix the missing mtd flash on linkstation lswtgl
- ARM: dts: kirkwood: use unique machine name for ds112
- ARM: dts: kirkwood: add kirkwood-ds112.dtb to Makefile
- ARM: OMAP2+: hwmod: fix _idle() hwmod state sanity check sequence
- perf/x86: Fix filter_events() bug with event mappings
- x86/LDT: Print the real LDT base address
- x86/apic/uv: Silence a shift wrapping warning
- ALSA: fm801: explicitly free IRQ line
- ALSA: fm801: propagate TUNER_ONLY bit when autodetected
- ALSA: fm801: detect FM-only card earlier
- netfilter: nfnetlink: use original skbuff when acking batches
- xfrm: fix crash in XFRM_MSG_GETSA netlink handler
- mwifiex: fix IBSS data path issue.
- mwifiex: add missing check for PCIe8997 chipset
- iwlwifi: set max firmware version of 7265 to 17
- Bluetooth: btmrvl: fix hung task warning dump
- dccp: limit sk_filter trim to payload
- net/mlx4_core: Do not BUG_ON during reset when PCI is offline
- mlxsw: pci: Correctly determine if descriptor queue is full
- PCI: Supply CPU physical address (not bus address) to iomem_is_exclusive()
- alpha/PCI: Call iomem_is_exclusive() for IORESOURCE_MEM, but not
IORESOURCE_IO
- vfio/pci: Allow VPD short read
- mlxsw: Treat local port 64 as valid
- IB/mlx4: Initialize hop_limit when creating address handle
- GRE: Disable segmentation offloads w/ CSUM and we are encapsulated via FOU
- powerpc/pci/of: Parse unassigned resources
- firmware: actually return NULL on failed request_firmware_nowait()
- c8sectpfe: Rework firmware loading mechanism
- net/mlx5: Avoid passing dma address 0 to firmware
- IB/mlx5: Fix RC
[Kernel-packages] [Bug 1876982] Re: tunnels over IPv6 are unencrypted when using IPsec
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- xenial' to 'verification-done-xenial'. If the problem still exists, change the tag 'verification-needed-xenial' to 'verification-failed- xenial'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-xenial -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1876982 Title: tunnels over IPv6 are unencrypted when using IPsec Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Fix Committed Status in linux source package in Bionic: In Progress Bug description: [Impact] When tunnels are configured over IPv6 using a xfrm policy, it's ignored. That means data will be unencrypted when it shouldn't. [Test case] Launch a VM with the given kernel and monitor its network link on the host with: tcpdump -n -i virbr0 ip6 and port 4789 In the guest, set up a tunnel using an IPv6 address: ip link add type vxlan id 5 remote fd00:cafe::2 dstport 4789 When setting the link up, observe packets being output on the host side: ip link set vxlan0 up Set the link down, and add a xfrm policy to block output to that given IPv6 address: ip link set vxlan0 down ip xfrm policy add dst fd00:cafe::2 dir out action block Check that using ping won't work with Operation not permitted: ping6 fd00:cafe::2 connect: Operation not permitted Set the vxlan link up and watch that no packets appear on tcpdump: ip link set vxlan0 up [Regression potential] Tunnels like VXLAN, GENEVE, etc, will stop to send. The test has shown that it still sends at least when no xfrm policy is configured. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1876982/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1876982] Re: tunnels over IPv6 are unencrypted when using IPsec
** Changed in: linux (Ubuntu Xenial) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1876982 Title: tunnels over IPv6 are unencrypted when using IPsec Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Fix Committed Status in linux source package in Bionic: In Progress Bug description: [Impact] When tunnels are configured over IPv6 using a xfrm policy, it's ignored. That means data will be unencrypted when it shouldn't. [Test case] Launch a VM with the given kernel and monitor its network link on the host with: tcpdump -n -i virbr0 ip6 and port 4789 In the guest, set up a tunnel using an IPv6 address: ip link add type vxlan id 5 remote fd00:cafe::2 dstport 4789 When setting the link up, observe packets being output on the host side: ip link set vxlan0 up Set the link down, and add a xfrm policy to block output to that given IPv6 address: ip link set vxlan0 down ip xfrm policy add dst fd00:cafe::2 dir out action block Check that using ping won't work with Operation not permitted: ping6 fd00:cafe::2 connect: Operation not permitted Set the vxlan link up and watch that no packets appear on tcpdump: ip link set vxlan0 up [Regression potential] Tunnels like VXLAN, GENEVE, etc, will stop to send. The test has shown that it still sends at least when no xfrm policy is configured. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1876982/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1876982] Re: tunnels over IPv6 are unencrypted when using IPsec
** Changed in: linux (Ubuntu Bionic) Importance: Undecided => High ** Changed in: linux (Ubuntu Bionic) Status: New => In Progress ** Changed in: linux (Ubuntu Bionic) Assignee: (unassigned) => Thadeu Lima de Souza Cascardo (cascardo) ** Changed in: linux (Ubuntu Xenial) Importance: Undecided => High ** Changed in: linux (Ubuntu Xenial) Status: New => In Progress ** Changed in: linux (Ubuntu Xenial) Assignee: (unassigned) => Thadeu Lima de Souza Cascardo (cascardo) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1876982 Title: tunnels over IPv6 are unencrypted when using IPsec Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: In Progress Bug description: [Impact] When tunnels are configured over IPv6 using a xfrm policy, it's ignored. That means data will be unencrypted when it shouldn't. [Test case] Launch a VM with the given kernel and monitor its network link on the host with: tcpdump -n -i virbr0 ip6 and port 4789 In the guest, set up a tunnel using an IPv6 address: ip link add type vxlan id 5 remote fd00:cafe::2 dstport 4789 When setting the link up, observe packets being output on the host side: ip link set vxlan0 up Set the link down, and add a xfrm policy to block output to that given IPv6 address: ip link set vxlan0 down ip xfrm policy add dst fd00:cafe::2 dir out action block Check that using ping won't work with Operation not permitted: ping6 fd00:cafe::2 connect: Operation not permitted Set the vxlan link up and watch that no packets appear on tcpdump: ip link set vxlan0 up [Regression potential] Tunnels like VXLAN, GENEVE, etc, will stop to send. The test has shown that it still sends at least when no xfrm policy is configured. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1876982/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1876982] Re: tunnels over IPv6 are unencrypted when using IPsec
** Description changed: [Impact] When tunnels are configured over IPv6 using a xfrm policy, it's ignored. That means data will be unencrypted when it shouldn't. [Test case] + Launch a VM with the given kernel and monitor its network link on the host with: + tcpdump -n -i virbr0 ip6 and port 4789 + + In the guest, set up a tunnel using an IPv6 address: + ip link add type vxlan id 5 remote fd00:cafe::2 dstport 4789 + + When setting the link up, observe packets being output on the host side: + ip link set vxlan0 up + + Set the link down, and add a xfrm policy to block output to that given IPv6 address: + ip link set vxlan0 down + ip xfrm policy add dst fd00:cafe::2 dir out action block + + Check that using ping won't work with Operation not permitted: + ping6 fd00:cafe::2 + connect: Operation not permitted + + Set the vxlan link up and watch that no packets appear on tcpdump: + ip link set vxlan0 up + [Regression potential] Tunnels like VXLAN, GENEVE, etc, will stop to send. The test has shown that it still sends at least when no xfrm policy is configured. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1876982 Title: tunnels over IPv6 are unencrypted when using IPsec Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: New Status in linux source package in Bionic: New Bug description: [Impact] When tunnels are configured over IPv6 using a xfrm policy, it's ignored. That means data will be unencrypted when it shouldn't. [Test case] Launch a VM with the given kernel and monitor its network link on the host with: tcpdump -n -i virbr0 ip6 and port 4789 In the guest, set up a tunnel using an IPv6 address: ip link add type vxlan id 5 remote fd00:cafe::2 dstport 4789 When setting the link up, observe packets being output on the host side: ip link set vxlan0 up Set the link down, and add a xfrm policy to block output to that given IPv6 address: ip link set vxlan0 down ip xfrm policy add dst fd00:cafe::2 dir out action block Check that using ping won't work with Operation not permitted: ping6 fd00:cafe::2 connect: Operation not permitted Set the vxlan link up and watch that no packets appear on tcpdump: ip link set vxlan0 up [Regression potential] Tunnels like VXLAN, GENEVE, etc, will stop to send. The test has shown that it still sends at least when no xfrm policy is configured. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1876982/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
