Bug#1032642: iproute2: ip tunnel change ip6gre to gre crashes with stack smash
On Mon, 3 Apr 2023 20:47:01 -0600 David Ahern wrote: > On 4/3/23 9:24 AM, Stephen Hemminger wrote: > > ted > >> > >> This happens because iproute2 just assumes the tunnel is ipv4, but the > >> kernel "knows" it's actually ip6gre so when calling the SIOCGETTUNNEL > >> ioctl it writes back a struct ip6_tnl_parm2 into the struct > >> ip_tunnel_parm which is smaller, so the stack gets overwritten. Is > >> there any way to tell from userspace whether a gre is v4 or v6 before > >> doing an ioctl? The ioctls don't take/return a size parameter as far > >> as I can see... > > > > Ip uses and IPv4 UDP socket when it thinks it is talking to GRE. > > And a IPv6 UDP socket when it is talking to GRE6. > > > > So the kernel could check and error out? > > > > Does seem like a kernel bug and a well known design flaw in ioctl > interface (assuming buffer of a specific size). The best iproute2 can do > is have `old_p` be a larger size (e.g., ip6_tnl_parm2) to avoid the > overrun, but then the result is nonsense with no way for it no an ipv6 > struct was passed back. The crash at least indicates something is off. I started to look into redoing the whole 'ip tunnel XXX' as just a remapping of arguments and calling the equivalent 'ip link ... type YYY' and it is doable for the basic stuff. Then starting looking at the Potential Router List (PRL) stuff. Looks like this is only supported through ioctl(). Definitely a dusty dark corner of networking code with rarely used features. Plus things like, the code to get PRL will allow bigger get if called from root vs non-root user??
Bug#1032642: iproute2: ip tunnel change ip6gre to gre crashes with stack smash
On Mon, 3 Apr 2023 20:47:01 -0600 David Ahern wrote: > On 4/3/23 9:24 AM, Stephen Hemminger wrote: > > ted > >> > >> This happens because iproute2 just assumes the tunnel is ipv4, but the > >> kernel "knows" it's actually ip6gre so when calling the SIOCGETTUNNEL > >> ioctl it writes back a struct ip6_tnl_parm2 into the struct > >> ip_tunnel_parm which is smaller, so the stack gets overwritten. Is > >> there any way to tell from userspace whether a gre is v4 or v6 before > >> doing an ioctl? The ioctls don't take/return a size parameter as far > >> as I can see... > > > > Ip uses and IPv4 UDP socket when it thinks it is talking to GRE. > > And a IPv6 UDP socket when it is talking to GRE6. > > > > So the kernel could check and error out? > > > > Does seem like a kernel bug and a well known design flaw in ioctl > interface (assuming buffer of a specific size). The best iproute2 can do > is have `old_p` be a larger size (e.g., ip6_tnl_parm2) to avoid the > overrun, but then the result is nonsense with no way for it no an ipv6 > struct was passed back. The crash at least indicates something is off. Actually any change tunnel can have similar issues where the tunnel is of one type and the request wants to change parameters. The two structs (ip_param and ip6_tunnel_param) are different enough that getting the incorrect type will be complete garbage. There doesn't seem to be a good way to identify the tunnel type. The only way I can see is to look at the link type (ifi_type) but this is ARPHRD_XXX value and not the ip protocol. The other way would be to query link info (with netlink) and make sure that IFLA_INFO_KIND (in IFLA_LINKINFO) matches when changing. Or maybe get rid of the ip tunnel command and just use ip link which is all netlink based. The iptunnel stuff was introduced long ago when the only way to make tunnels was with ioctl. Now you can do same operations with ip link. to
Bug#1032642: iproute2: ip tunnel change ip6gre to gre crashes with stack smash
ted > > This happens because iproute2 just assumes the tunnel is ipv4, but the > kernel "knows" it's actually ip6gre so when calling the SIOCGETTUNNEL > ioctl it writes back a struct ip6_tnl_parm2 into the struct > ip_tunnel_parm which is smaller, so the stack gets overwritten. Is > there any way to tell from userspace whether a gre is v4 or v6 before > doing an ioctl? The ioctls don't take/return a size parameter as far > as I can see... Ip uses and IPv4 UDP socket when it thinks it is talking to GRE. And a IPv6 UDP socket when it is talking to GRE6. So the kernel could check and error out?
Bug#1032642: iproute2: ip tunnel change ip6gre to gre crashes with stack smash
On Sun, 2 Apr 2023 23:58:52 +0100
Luca Boccassi wrote:
> On Sat, 25 Mar 2023 at 00:39, Bernhard Übelacker
> wrote:
> >
> > Dear Maintainer,
> > I tried to find out where exactly the stack smashing takes place.
> > And found the ioctl SIOCCHGTUNNEL did write more than the 52 bytes
> > allocated in variable old_p, by that overwriting the stack canary.
> >
> > Kind regards,
> > Bernhard
> >
> >
> > (gdb)
> > 0x5557589f 62 {
> > 1: x/i $pc
> > => 0x5557589f : mov%fs:0x28,%rax
> > (gdb)
> > 0x555758a8 62 {
> > 1: x/i $pc
> > => 0x555758a8 : mov%rax,0x68(%rsp)
> > (gdb) print/x $rax
> > $1 = 0xbf9b77d893accd00
> > (gdb) print/x $rsp + 0x68
> > $2 = 0x7fffea28
> >
> >
> > (gdb)
> > 0x77e575f5 120 in ../sysdeps/unix/syscall-template.S
> > 1: x/i $pc
> > => 0x77e575f5 :syscall
> > 2: /x *(uint64_t*)0x7fffea28 = 0xbf9b77d893accd00
> > (gdb) bt
> > #0 0x77e575f5 in ioctl () at ../sysdeps/unix/syscall-template.S:120
> > #1 0x55578230 in tnl_get_ioctl (basedev=0x7fffee8f "gre1",
> > p=) at tunnel.c:77
> > #2 0x55576243 in parse_args (argc=9, argv=0x7fffec50,
> > cmd=35315, p=0x7fffea70) at iptunnel.c:181
> > #3 0x555762fb in do_add (cmd=35315, argc=,
> > argv=) at iptunnel.c:260
> > #4 0x5556258b in do_cmd (argv0=0x7fffee81 "tunnel", argc=11,
> > argv=0x7fffec40) at ip.c:133
> > #5 0x55561fc2 in main (argc=12, argv=0x7fffec38) at ip.c:344
> > (gdb) stepi
> > 0x77e575f7 120 in ../sysdeps/unix/syscall-template.S
> > 1: x/i $pc
> > => 0x77e575f7 :cmp$0xf001,%rax
> > 2: /x *(uint64_t*)0x7fffea28 = 0x200
> >
> > (gdb) print _p
> > $7 = (struct ip_tunnel_parm *) 0x7fffe9f0
> > (gdb) print sizeof(old_p)
> > $8 = 52
> > (gdb) print/x 0x7fffe9f0 + 52
> > $9 = 0x7fffea24
> >
> > (gdb) list iptunnel.c:181
> > 178 if (cmd == SIOCCHGTUNNEL && count == 0) {
> > 179 struct ip_tunnel_parm old_p = {};
> > 180
> > 181 if (tnl_get_ioctl(*argv, _p))
> > 182 return -1;
>
> Hi David and Stephen,
>
> To reproduce, build iproute2 with -fstack-protector-strong in CFLAGS, and run:
>
> ip tunnel add gre1 mode ip6gre local 2001:db8::1 remote 2001:db8::2 ttl 255
> ip tunnel change gre1 mode gre local 192.168.0.0 remote 192.168.0.1 ttl 255
>
> You'll get:
>
> *** stack smashing detected ***: terminated
> Aborted
>
> This happens because iproute2 just assumes the tunnel is ipv4, but the
> kernel "knows" it's actually ip6gre so when calling the SIOCGETTUNNEL
> ioctl it writes back a struct ip6_tnl_parm2 into the struct
> ip_tunnel_parm which is smaller, so the stack gets overwritten. Is
> there any way to tell from userspace whether a gre is v4 or v6 before
> doing an ioctl? The ioctls don't take/return a size parameter as far
> as I can see...
Is setting IPv4 addresses on an IPv6 tunnel even a valid operation?
Assuming the ioctl to get is fixed, is there a reason to allow it?
One more reason netlink is better than ioctl.
Bug#934848: linux-image-4.19.0-5-amd64: The Cavium PTP device driver is always loaded
Package: src:linux Version: 4.19.37-5+deb10u2 Severity: normal Dear Maintainer, The Cavium PTP coprocess as PTP clock driver is rarely if ever present on x86 systems, yet the Debian kernel config has it enabled. Noticed this as driver in /sys/bus/pci/drivers on a standard x86 server. The fix is simple, since this is a PCI device and can be built as a module, just change the kernel config to build as module. CONFIG_CAVIUM_PTP=m -- Package-specific info: ** Version: Linux version 4.19.0-5-amd64 (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.37-5+deb10u2 (2019-08-08) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 root=UUID=ae541fd6-fbff-48ce-ba8b-57840d9992d0 ro quiet ** Not tainted ** Kernel log: [ 14.102093] sd 1:0:0:0: Attached scsi generic sg2 type 0 [ 14.102134] sr 8:0:0:0: Attached scsi generic sg3 type 5 [ 14.102998] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [ 14.120054] input: PC Speaker as /devices/platform/pcspkr/input/input8 [ 14.139416] RAPL PMU: API unit is 2^-32 Joules, 3 fixed counters, 655360 ms ovfl timer [ 14.139418] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules [ 14.139419] RAPL PMU: hw unit of domain package 2^-14 Joules [ 14.139420] RAPL PMU: hw unit of domain dram 2^-16 Joules [ 14.152308] EFI Variables Facility v0.08 2004-May-17 [ 14.159835] pstore: Registered efi as persistent store backend [ 14.160040] systemd-journald[420]: Received request to flush runtime journal from PID 1 [ 14.171072] Loading iSCSI transport class v2.0-870. [ 14.172013] checking generic (fa00 50) vs hw (fa00 100) [ 14.172014] fb: switching to astdrmfb from EFI VGA [ 14.172050] Console: switching to colour dummy device 80x25 [ 14.172494] [drm] Using P2A bridge for configuration [ 14.172497] [drm] AST 2400 detected [ 14.172507] [drm] Analog VGA only [ 14.172521] [drm] dram MCLK=408 Mhz type=1 bus_width=16 size=0100 [ 14.173232] snd_hda_intel :00:1b.0: enabling device (0140 -> 0142) [ 14.173335] [TTM] Zone kernel: Available graphics memory: 16408614 kiB [ 14.173336] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [ 14.173337] [TTM] Initializing pool allocator [ 14.173339] [TTM] Initializing DMA pool allocator [ 14.177685] fbcon: astdrmfb (fb0) is primary device [ 14.198073] Console: switching to colour frame buffer device 128x48 [ 14.216339] ast :0a:00.0: fb0: astdrmfb frame buffer device [ 14.227981] iscsi: registered transport (iser) [ 14.254552] [drm] Initialized ast 0.1.0 20120228 for :0a:00.0 on minor 0 [ 14.254794] snd_hda_codec_realtek hdaudioC0D0: ALC1150: SKU not ready 0x [ 14.255267] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC1150: line_outs=3 (0x14/0x15/0x16/0x0/0x0) type:line [ 14.255268] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 14.255269] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 (0x1b/0x0/0x0/0x0/0x0) [ 14.255269] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0 [ 14.255270] snd_hda_codec_realtek hdaudioC0D0:dig-out=0x1e/0x0 [ 14.255270] snd_hda_codec_realtek hdaudioC0D0:inputs: [ 14.255271] snd_hda_codec_realtek hdaudioC0D0: Front Mic=0x19 [ 14.255272] snd_hda_codec_realtek hdaudioC0D0: Rear Mic=0x18 [ 14.255273] snd_hda_codec_realtek hdaudioC0D0: Line=0x1a [ 14.266764] input: HDA Digital PCBeep as /devices/pci:00/:00:1b.0/sound/card0/input9 [ 14.275334] input: HDA Intel PCH Front Mic as /devices/pci:00/:00:1b.0/sound/card0/input10 [ 14.275396] input: HDA Intel PCH Rear Mic as /devices/pci:00/:00:1b.0/sound/card0/input11 [ 14.275468] input: HDA Intel PCH Line as /devices/pci:00/:00:1b.0/sound/card0/input12 [ 14.275511] input: HDA Intel PCH Line Out Front as /devices/pci:00/:00:1b.0/sound/card0/input13 [ 14.275578] input: HDA Intel PCH Line Out Surround as /devices/pci:00/:00:1b.0/sound/card0/input14 [ 14.275636] input: HDA Intel PCH Line Out CLFE as /devices/pci:00/:00:1b.0/sound/card0/input15 [ 14.275688] input: HDA Intel PCH Front Headphone as /devices/pci:00/:00:1b.0/sound/card0/input16 [ 14.288003] RPC: Registered named UNIX socket transport module. [ 14.288004] RPC: Registered udp transport module. [ 14.288004] RPC: Registered tcp transport module. [ 14.288005] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 14.308698] RPC: Registered rdma transport module. [ 14.308698] RPC: Registered rdma backchannel transport module. [ 14.316218] EDAC sbridge: Seeking for: PCI ID 8086:6fa0 [ 14.316233] EDAC sbridge: Seeking for: PCI ID 8086:6fa0 [ 14.316249] EDAC sbridge: Seeking for: PCI ID 8086:6f60 [ 14.316259] EDAC sbridge: Seeking for: PCI ID 8086:6fa8 [ 14.316263] EDAC sbridge: Seeking for: PCI ID 8086:6fa8 [ 14.316270] EDAC sbridge: Seeking for: PCI ID 8086:6f71 [ 14.316274] EDAC sbridge:
Re: Iproute2 for Debian testing and backports
On Thu, 14 Dec 2017 08:26:07 +0100 Alexander Wirt <formo...@formorer.de> wrote: > On Wed, 13 Dec 2017, Stephen Hemminger wrote: > > > Iproute2 gains new features every release to keep up with the upstream > > kernel. > > > > How do I request that iproute for Debian testing (buster) and backports > > (stretch-backports) > > be kept in sync? > > kernel iproute > > sid 4.144.9 > > buster 4.134.9 > > stretch-backports 4.134.9 > > stretch 4.9 4.9 > > > > Do you need resources to be applied to Debian maintenance for this? > Yes, we need more manpower. > > Alex I am not an official Debian maintainer but could make a tree on github that was ready to go. David could also feed any Cumulus patches back in.
Iproute2 for Debian testing and backports
Iproute2 gains new features every release to keep up with the upstream kernel. How do I request that iproute for Debian testing (buster) and backports (stretch-backports) be kept in sync? kernel iproute sid 4.144.9 buster 4.134.9 stretch-backports 4.134.9 stretch 4.9 4.9 Do you need resources to be applied to Debian maintenance for this?
Bug#678461: linux-image-3.0.0-1-amd64: e1000e driver for onboard Intel Corporation
On Thu, 21 Jun 2012 19:26:07 -0400 Attila Mate m...@sci.brooklyn.cuny.edu wrote: Package: linux-2.6 Version: 3.0.0-3 Severity: normal .. A lot of the E1000 issues are related to ASPM (power management) kicking in and stopping the device. There are some fixes in 3.2 kernel to deal with this. You can follow the details over on the e1000-devel mailing list. The problem seems inter-related with BIOS and chip versions. https://lwn.net/Articles/449448/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120621172851.342cf...@nehalam.linuxnetplumber.net
Bug#609994: sky2: hw csum failure
On Mon, 28 Nov 2011 12:10:20 + Vincent Blut vincent.deb...@free.fr wrote: Hi, [reference: http://bugs.debian.org/609994] I have a Marvell ethernet controller which presents some failures when 'rx checksumming' is enabled, here is the model: $ lspci -vvs 03:00.0 03:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 15) Subsystem: Micro-Star International Co., Ltd. Marvell 88E8053 Gigabit Ethernet Controller (MSI) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 44 Region 0: Memory at fdbfc000 (64-bit, non-prefetchable) [size=16K] Region 2: I/O ports at 7c00 [size=256] [virtual] Expansion ROM at fda0 [disabled] [size=128K] Capabilities: access denied Kernel driver in use: sky2 At first I thought it was due to the MTU size, so I tested different values but unfortunately without positive effect. Overall this issue appears randomly when the incoming traffic is high. I tested 2.6.32, 3.1.1, and 3.2-rc3, sadly all are affected. Finally, the only way to avoid those failures is to disabled 'rx checksumming' (ethtool -K ethX rx off). Here is the stack trace: [ 14.615648] sky2 :03:00.0: eth1: enabling interface [ 14.616452] ADDRCONF(NETDEV_UP): eth1: link is not ready [ 17.094194] sky2 :03:00.0: eth1: Link is up at 1000 Mbps, full duplex, flow control both [ 17.094887] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 28.080018] eth1: no IPv6 routers present [ 563.816032] sky2 :03:00.0: eth1: hung mac 124:22 fifo 195 (150:145) [ 563.816036] sky2 :03:00.0: eth1: receiver hang detected [ 567.005422] sky2 :03:00.0: eth1: Link is up at 1000 Mbps, full duplex, flow control both [ 1040.816314] sky2 :03:00.0: eth1: rx error, status 0x7ffc0001 length 1004 [ 2097.401616] sky2 :03:00.0: eth1: rx error, status 0x39a339a3 length 0 This isn't really a hardware checksum failure. Your problem is deeper than that. The internal parts of the chip are not communicating correctly. The hung mac is a problem only occurs if the PCI is really stuck. There may be a timing issue on your motherboard, or the BIOS isn't setting up the device properly. The timing then gets messed up between the end of frame status and the PCI shared memory region. Turning checksum off masks the problem, but the status is probably still corrupt. In either case the problem is beyond the ability of the driver to fix or workaround. Your best bet is to see if there is a BIOS update, or replace the hardware. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2028085030.248eb...@nehalam.linuxnetplumber.net
Bug#645589: linux-image-3.0.0-2-amd64: sky2 rx errors on 3.0, 2.6.32 works
On Tue, 18 Oct 2011 04:43:06 +0100 Ben Hutchings b...@decadent.org.uk wrote: On Mon, 2011-10-17 at 10:40 +0300, Antti Salmela wrote: Package: linux-2.6 Version: 3.0.0-5 Severity: normal sky2 loses packets on 3.0 (-3 and -5) and 3.1-rc7, 2.6.32-38 and setting interface to promiscuous works. [ 60.118244] sky2 :02:00.0: eth0: rx error, status 0xb92100 length 185 [ 62.664370] sky2 :02:00.0: eth0: rx error, status 0x602100 length 96 [ 63.370051] sky2 :02:00.0: eth0: rx error, status 0x422100 length 66 [ 63.714672] sky2 :02:00.0: eth0: rx error, status 0x722100 length 114 [ 64.513458] device eth0 entered promiscuous mode It looks like this is a bug in accounting of VLAN tags, though I don't see what difference promiscuous mode should make. The log messages show that status has the VLAN flag (bit 13) set and the length field (bits 16:28) equals the length passed into sky2_receive(), but that function expects the length field to be greater by VLAN_HLEN. This device is: [...] 02:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller [11ab:4362] (rev 19) Subsystem: ASUSTeK Computer Inc. Marvell 88E8053 Gigabit Ethernet controller PCIe (Asus) [1043:8142] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 16 bytes Interrupt: pin A routed to IRQ 43 Region 0: Memory at cdefc000 (64-bit, non-prefetchable) [size=16K] Region 2: I/O ports at c800 [size=256] Expansion ROM at cdec [disabled] [size=128K] Capabilities: access denied Kernel driver in use: sky2 [...] The accounting is supposed to be: MAC = total length of packet (including vlan) DMA = bytes dma'd to buffer (does not include vlan) Looks like the code is incorrect for the case where hardware VLAN stripping is disabled. What happens is that status bit still has the VLAN flag, but DMA engine leaves the VLAN tag in the DMA buffer so the check fails. Proper accounting would involve more state machine mechanics about whether VLAN tag has already been seen in current receive status ring. For now probably best to do something like: --- net-next.orig/drivers/net/ethernet/marvell/sky2.c 2011-10-18 11:09:04.108683763 -0700 +++ net-next/drivers/net/ethernet/marvell/sky2.c2011-10-18 11:09:53.661264323 -0700 @@ -2543,7 +2543,8 @@ static struct sk_buff *sky2_receive(stru struct sk_buff *skb = NULL; u16 count = (status GMR_FS_LEN) 16; - if (status GMR_FS_VLAN) + if ((dev-features NETIF_F_HW_VLAN_RX) + (status GMR_FS_VLAN)) count -= VLAN_HLEN; /* Account for vlan tag */ netif_printk(sky2, rx_status, KERN_DEBUG, dev, -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111018111308.2c5a6...@nehalam.linuxnetplumber.net
Bug#625914: [Bridge] Bug#625914: linux-image-2.6.38-2-amd64: bridging is not interacting well with multicast in 2.6.38-4
On Tue, 10 May 2011 16:35:40 -0700 Noah Meyerhans no...@debian.org wrote: On Tue, May 10, 2011 at 03:11:00PM -0700, Stephen Hemminger wrote: There were two more follow on commits in stable related to this. I recommend merging 2.6.38.6 which includes these. The problem still exists in the current 2.6.38.6. Backing out 5f1c356a still solves the problem there. I have not yet tried anything outside the stable-2.6.38.y tree, but it seems like these same changes are present there, and it's unlikely that other releases will work any better. noah Is this unique to the tap interfaces or does bridging multicast not work for all devices? -- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110513110326.60fa09b4@nehalam
Bug#625914: [Bridge] Bug#625914: linux-image-2.6.38-2-amd64: bridging is not interacting well with multicast in 2.6.38-4
On Thu, 12 May 2011 15:59:16 -0700 (PDT) David Miller da...@davemloft.net wrote: From: Noah Meyerhans no...@debian.org Date: Tue, 10 May 2011 16:35:40 -0700 On Tue, May 10, 2011 at 03:11:00PM -0700, Stephen Hemminger wrote: There were two more follow on commits in stable related to this. I recommend merging 2.6.38.6 which includes these. The problem still exists in the current 2.6.38.6. Backing out 5f1c356a still solves the problem there. I have not yet tried anything outside the stable-2.6.38.y tree, but it seems like these same changes are present there, and it's unlikely that other releases will work any better. So the issue is that if we back out that change, we get crashes. Aparently there is a code path where whatever is existing in the SKB ip options block matters, and needs to be maintained. Someone needs to audit all of this and figure out how to fix the problem properly. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html I suspect tuntap is part of the problem. The skb may not be allocated with enough padding or something like that. No guarantees but will do some investigation. -- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110512162810.34b8d55a@nehalam
Bug#625914: [Bridge] Bug#625914: linux-image-2.6.38-2-amd64: bridging is not interacting well with multicast in 2.6.38-4
On Tue, 10 May 2011 16:35:40 -0700
Noah Meyerhans no...@debian.org wrote:
On Tue, May 10, 2011 at 03:11:00PM -0700, Stephen Hemminger wrote:
There were two more follow on commits in stable related to this.
I recommend merging 2.6.38.6 which includes these.
The problem still exists in the current 2.6.38.6. Backing out 5f1c356a
still solves the problem there.
I have not yet tried anything outside the stable-2.6.38.y tree, but it
seems like these same changes are present there, and it's unlikely that
other releases will work any better.
Does this fix the problem? The tap driver allocates an skb and throws
it into the receive path, but the skb does not have the same padding
as normal skb's received.
--- a/drivers/net/tun.c 2011-05-12 16:36:15.231347935 -0700
+++ b/drivers/net/tun.c 2011-05-12 16:36:38.503464573 -0700
@@ -614,7 +614,7 @@ static __inline__ ssize_t tun_get_user(s
}
if ((tun-flags TUN_TYPE_MASK) == TUN_TAP_DEV) {
- align = NET_IP_ALIGN;
+ align = NET_IP_ALIGN + NET_SKB_PAD;
if (unlikely(len ETH_HLEN ||
(gso.hdr_len gso.hdr_len ETH_HLEN)))
return -EINVAL;
--
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110512164322.45626683@nehalam
Bug#625914: [Bridge] Bug#625914: linux-image-2.6.38-2-amd64: bridging is not interacting well with multicast in 2.6.38-4
On Tue, 10 May 2011 11:05:40 -0700 Noah Meyerhans no...@debian.org wrote: On Tue, May 10, 2011 at 01:42:49PM +0100, Ben Hutchings wrote: This is pretty weird. Debian version 2.6.38-3 has a few bridging changes from stable 2.6.38.3 and 2.6.38.4, but they don't look like they would cause this. I have apparently filed the bug against the wrong version of Debian's kernel. 2.6.38-3 is not affected, and works as expected. The change was introduced in -4. That may have been clear from the report itself, but the report was filed against -3. I've fixed that in the BTS. I gathered that, and then made the same mistake in writing the above! The version with the regression, 2.6.38-4, includes the changes from stable 2.6.38.3 and 2.6.38.4 With a little help from git bisect, I've tracked this regression down to the following commit to the stable-2.6.38.y tree: commit 5f1c356a3fadc0c19922d660da723b79bcc9aad7 Author: Herbert Xu herb...@gondor.apana.org.au Date: Fri Mar 18 05:27:28 2011 + bridge: Reset IPCB when entering IP stack on NF_FORWARD [ Upstream commit 6b1e960fdbd75dcd9bcc3ba5ff8898ff1ad30b6e ] Whenever we enter the IP stack proper from bridge netfilter we need to ensure that the skb is in a form the IP stack expects it to be in. The entry point on NF_FORWARD did not meet the requirements of the IP stack, therefore leading to potential crashes/panics. This patch fixes the problem. Signed-off-by: Herbert Xu herb...@gondor.apana.org.au Acked-by: Stephen Hemminger shemmin...@vyatta.com Signed-off-by: David S. Miller da...@davemloft.net Signed-off-by: Greg Kroah-Hartman gre...@suse.de The diff is diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c index 4b5b66d..49d50ea 100644 --- a/net/bridge/br_netfilter.c +++ b/net/bridge/br_netfilter.c @@ -741,6 +741,9 @@ static unsigned int br_nf_forward_ip(unsigned int hook, struct sk_buff *skb, nf_bridge-mask |= BRNF_PKT_TYPE; } + if (br_parse_ip_options(skb)) + return NF_DROP; + /* The physdev module checks on this */ nf_bridge-mask |= BRNF_BRIDGED; nf_bridge-physoutdev = skb-dev; If I revert this change, network connectivity functions as expected for the VMs on this host. I don't know enough about this change or the problem it was supposed to solve to be able to guess about what's going wrong. noah There were two more follow on commits in stable related to this. I recommend merging 2.6.38.6 which includes these. -- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110510151100.52a9f8fa@nehalam
Bug#625914: linux-image-2.6.38-2-amd64: bridging is not interacting well with multicast in 2.6.38-4
On Tue, 10 May 2011 03:38:44 +0100 Ben Hutchings b...@decadent.org.uk wrote: On Fri, 2011-05-06 at 13:12 -0700, Noah Meyerhans wrote: Package: linux-2.6 Version: 2.6.38-3 Severity: normal Hi. I've got a system that hosts several kvm virtual hosts. The VMs access the network via tap devices bridged with a physical interface. After upgrading to linux-image-2.6.38-2-amd64_2.6.38-4, I noticed that the virtualhosts were not autoconfiguring their IPv6 interfaces. Debugging revealed that no multicast was passing over the bridge. The bridge configuration is: bridge name bridge id STP enabled interfaces br0 8000.0002e3080eb5 no eth1 tap0 tap1 tap2 If I attach tcpdump to br0, I can see multicast (e.g. IPv6 Neighbor Solicitation) packets. However, if I attach tcpdump to eth1, I do not see multicast packets sourced from one of the VMs. Downgrading to 2.6.38-3 solves the problem. This is pretty weird. Debian version 2.6.38-3 has a few bridging changes from stable 2.6.38.3 and 2.6.38.4, but they don't look like they would cause this. Ben. There are two possible explainations: 1. In 2.6.37 and kernels the bridge uses IGMP snooping, there were several fixes to that in the stable kernel; especially related to IPv6. 2. There was also a recent change to block link local multicast address. But that should impact what you are doing. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110509201528.52d87ec4@nehalam
Bug#564628: [PATCH] net/r8169: Correct the ram code for RTL8111D(L)
On Tue, 30 Nov 2010 00:33:34 +0100 Francois Romieu rom...@fr.zoreil.com wrote: hayeswang hayesw...@realtek.com : Excuse me, I have some questions about the firmware patch. 1. I should convert the data into the binary files (.bin). Is it right? You may do it. Fwiw I have cooked something for it in the attached patch #9 this WE. Feel free to take bits from it. I will not do more changes while you work on it. 2. Where should I update the firmware files? Is the path the linux-2.6/firmware? ! This directory is only here to contain firmware images extracted from old ! device drivers which predate the common use of request_firmware(). It is fine for the existing code. However, according to linux-2.6/firmeware/README.AddingFirmware, I should update they to another repository: git://git.kernel.org/pub/scm/linux/kernel/git/dwmw2/linux-firmware.git /me scratches head. Assuming Realtek does not intend to stand this code / data as GPLable, yes. It will help people staying clear from non-free code, it will help packaging something useful and it will remove some cruft from the code. So everybody will end happy. Especially after an aspirin. The plan is to do away with linux-2.6/firmware entirely. Distributions are shipping the firmware from linux-firmware, not the kernel files. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101129161344.05923...@nehalam
Re: [PATCH 2/3] econet: Move to staging
On Tue, 23 Nov 2010 03:52:28 + Ben Hutchings b...@decadent.org.uk wrote: Recent review has revealed several bugs in obscure protocol implementations that can be exploited by local users for denial of service or privilege escalation. The econet protocol (PF_ECONET) is unmaintained. There appear to be no published applications for it, and it has never progressed beyond 'experimental' status. This protocol generally should not be enabled by distributions, since the cost of a security flaw affecting all installed systems presumably outweighs the benefit to the few (if any) legitimate users. Signed-off-by: Ben Hutchings b...@decadent.org.uk This I agree with. Probably the Arcnet devices as well. Most distro's don't enable it anyway. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101122203236.029c8...@nehalam
Re: [PATCH 1/3] decnet: Move to staging
On Tue, 23 Nov 2010 03:51:53 + Ben Hutchings b...@decadent.org.uk wrote: Recent review has revealed several bugs in obscure protocol implementations that can be exploited by local users for denial of service or privilege escalation. The decnet protocol (PF_DECnet) is unmaintained. Since 2.6.12-rc2 the only changes appear to be adjustments for net API changes and fixes for bugs found by inspection. This protocol generally should not be enabled by distributions, since the cost of a security flaw affecting all installed systems presumably outweighs the benefit to the few (if any) legitimate users. Signed-off-by: Ben Hutchings b...@decadent.org.uk NAK there are still users and stuff does get fixed. If you don't like it then disable it from config. -- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101122203131.7cbd6...@nehalam
Re: [PATCH 3/3] x25: Move to staging
On Tue, 23 Nov 2010 03:55:28 + Ben Hutchings b...@decadent.org.uk wrote: Recent review has revealed several bugs in obscure protocol implementations that can be exploited by local users for denial of service or privilege escalation. The x25 protocol (PF_X25) receives only 'odd fixes'. There appear to be no published applications for it, and it has never progressed beyond 'experimental' status. This protocol generally should not be enabled by distributions, since the cost of a security flaw affecting all installed systems presumably outweighs the benefit to the few (if any) legitimate users. Signed-off-by: Ben Hutchings b...@decadent.org.uk --- I'm somewhat less sure about this one; maybe it's improving? But there is little enough sign of any usefulness after 10 years. There are several X25 dependencies that presumably should be moved too. No. If you don't like it then don't enable it. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101122203155.27534...@nehalam
Bug#477589: linux-image-2.6.22-3-k7: BIC should not be default TCP congestion control
Package: linux-image-2.6.22-3-k7 Version: 2.6.22-6.lenny1 Severity: normal The default congestion control choice in the Lenny kernel configuration is BIC. This is a poor choice because BIC has a number of problems and was replacede by CUBIC in 2.6.20 or so kernel release. Debian seems to have continued carrying forward an old configuration file and continued using BIC. This is important because BIC is unfair and could have a negative impact on overall Internet congestion. PLEASE FIX, it is trivial to change the kernel config to either use CUBIC, RENO or H-TCP any of these are stable and safe choices. The kernel.org default (used by other distro's as well) is CUBIC, RENO is the same as old 2.4 Linux for you conservative Debian types, and H-TCP is for the alternative crowd. -- Package-specific info: ** Version: Linux version 2.6.22-3-k7 (Debian 2.6.22-6.lenny1) ([EMAIL PROTECTED]) (gcc version 4.1.3 20071209 (prerelease) (Debian 4.1.2-18)) #1 SMP Sun Feb 10 21:04:14 UTC 2008 ** Not tainted ** Kernel log: skge eth0: Link is up at 1000 Mbps, full duplex, flow control both skge eth0: disabling interface skge eth0: enabling interface ADDRCONF(NETDEV_UP): eth0: link is not ready skge eth0: Link is up at 1000 Mbps, full duplex, flow control both ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready eth0: no IPv6 routers present skge eth0: disabling interface skge eth0: enabling interface ADDRCONF(NETDEV_UP): eth0: link is not ready skge eth0: Link is up at 1000 Mbps, full duplex, flow control both ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready eth0: no IPv6 routers present skge eth0: Link is down. skge eth0: Link is up at 100 Mbps, full duplex, flow control none skge eth0: Link is down. skge eth0: Link is up at 1000 Mbps, full duplex, flow control both skge eth0: disabling interface skge eth0: enabling interface ADDRCONF(NETDEV_UP): eth0: link is not ready skge eth0: Link is up at 1000 Mbps, full duplex, flow control both ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready eth0: no IPv6 routers present skge eth0: Link is down. skge eth0: Link is up at 100 Mbps, full duplex, flow control none skge eth0: Link is down. skge eth0: Link is up at 1000 Mbps, full duplex, flow control both skge eth0: disabling interface skge eth0: enabling interface ADDRCONF(NETDEV_UP): eth0: link is not ready skge eth0: Link is up at 1000 Mbps, full duplex, flow control both ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready skge eth0: Link is down. skge eth0: Link is up at 100 Mbps, full duplex, flow control none eth0: no IPv6 routers present skge eth0: Link is down. skge eth0: Link is up at 1000 Mbps, full duplex, flow control both skge eth0: disabling interface skge eth0: enabling interface ADDRCONF(NETDEV_UP): eth0: link is not ready skge eth0: Link is up at 1000 Mbps, full duplex, flow control both ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready eth0: no IPv6 routers present skge eth0: disabling interface skge eth0: enabling interface ADDRCONF(NETDEV_UP): eth0: link is not ready skge eth0: Link is up at 1000 Mbps, full duplex, flow control both ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready eth0: no IPv6 routers present skge eth0: Link is down. skge eth0: Link is up at 100 Mbps, full duplex, flow control none skge eth0: Link is down. skge eth0: Link is up at 1000 Mbps, full duplex, flow control both skge eth0: disabling interface skge eth0: enabling interface ADDRCONF(NETDEV_UP): eth0: link is not ready skge eth0: Link is up at 1000 Mbps, full duplex, flow control both ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready eth0: no IPv6 routers present skge eth0: Link is down. skge eth0: Link is up at 100 Mbps, full duplex, flow control none skge eth0: Link is down. skge eth0: Link is up at 1000 Mbps, full duplex, flow control both skge eth0: disabling interface skge eth0: enabling interface ADDRCONF(NETDEV_UP): eth0: link is not ready skge eth0: Link is up at 1000 Mbps, full duplex, flow control both ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready eth0: no IPv6 routers present skge eth0: Link is down. skge eth0: Link is up at 100 Mbps, full duplex, flow control none skge eth0: Link is down. skge eth0: Link is up at 1000 Mbps, full duplex, flow control both skge eth0: Link is down. skge eth0: Link is up at 100 Mbps, full duplex, flow control none skge eth0: Link is down. skge eth0: Link is up at 1000 Mbps, full duplex, flow control both skge eth0: disabling interface tcpdump uses obsolete (PF_INET,SOCK_PACKET) device eth1 entered promiscuous mode audit(1208996809.980:2): dev=eth1 prom=256 old_prom=0 auid=4294967295 device eth1 left promiscuous mode audit(1208996809.980:3): dev=eth1 prom=0 old_prom=256 auid=4294967295 device eth1 entered promiscuous mode audit(1208996822.481:4): dev=eth1 prom=256 old_prom=0 auid=4294967295 device eth1 left promiscuous mode audit(1208996823.481:5): dev=eth1 prom=0 old_prom=256 auid=4294967295 device eth1 entered promiscuous mode audit(1208996829.481:6): dev=eth1 prom=256 old_prom=0
Bug#411115: sky2 module
On Fri, 16 Feb 2007 12:32:12 +0100 maximilian attems [EMAIL PROTECTED] wrote: reassign 45 linux-2.6 severity 45 important tags 45 patch stop On Fri, Feb 16, 2007 at 08:37:27AM -0200, Renato S. Yamane wrote: Package: Kernel Version: 2.6.18-4 Stephen Hemminger post some patchs to sky2 module in: https://lists.osdl.org/mailman/private/sk-drivers/2007-February/11.html we are currently under freeze, i had no sky2 test box until now. some of the patches qualify for a stable release update, i'll check with dannf which we'll add. thanks a lot for your mail I sent two patches out for 2.6.20 stable last week. -- Stephen Hemminger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396185: sky2 freezes in 2.6.17-2-686. Maintainer confirms that it should be fixed in 2.6.19-git tree.
On Sun, 17 Dec 2006 17:15:47 +0300 Evgeniy Polyakov [EMAIL PROTECTED] wrote: On Wed, Nov 29, 2006 at 08:29:48AM +0300, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: Here is link to discussion: http://marc.theaimsgroup.com/?l=linux-netdevm=116227512815783w=2 can you try the linux-image 2.6.18, they are in unstable and the etch release images. 2.6.18-1-686 kernel still allows to freeze sky2. Fix didn't go in until 2.6.18.2 fix is in the 2.6.18-2-686 linux image, you'd better update your test box. Just for clarification: there are at least two bugs described - one in the above link, and this new one. The former could only be fixed by reboot, the latter - by rmmod/modprobe sequence. The former had special info in dmesg, the latter does not. Hopefully they both are fixed in 2.6.18-2. I will set it up as soon as time permits (it is my main desktop, which is rarely turned off) and report if problem still persists. Bug still exists in 2.6.18-2 (package version 5). Can be 'fixed' by rmmod/modprobe sequence though. Is not easily reproducible. Bug with freeze also exists in 2.6.18-3 (package version 2.6.18-7) - no messages in dmesg, no interrupts. It is dual lan board with only one port being used. rmmod/modprobe sequence brings NIC back to working mode. What are the statistics (ethtool -S eth0) after the hang. One user reported a single pause frame being sent. I have can't reproduce a hang with similar hardware, so am beginning to wonder if the problem is pause negotiation, and interoperability problems?? Maybe the receiver gets overloaded and sends one pause frame, but the switch can't really do flow control and gets stuck. I do stress tests with either a direct connect cable, or with a switch that does flow control and lots of packets and see the driver/hardware successfully doing flow control. -- Stephen Hemminger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341801: skge error; hangs w/ hardware memory hole
On Mon, 3 Jul 2006 22:52:38 +0200 Martin Michlmayr [EMAIL PROTECTED] wrote: We received the following bug report at http://bugs.debian.org/341801 | I have a Asus A8V with 4GB of RAM. When I turn on the hardware memory | hole in the BIOS, the skge driver prints out this message: | skge hardware error detected (status 0xc00) | and then does not work. Setting debug=16 doesn't really show anything. Another users confirms this bug, saying: | I'm running kernel 2.6.15-1-amd64-generic version 2.6.15-6, and see | the very same thing. | So I have to turn off the memory remapping feature that allows the | system to see all 4 gig of memory, and thus lose the use of about 200 | megabytes of memory. | Hardware: ASUS A8V Deluxe, 4G RAM, Athlon 64 3200+ CPU. This problem has probably been there forever and also happens with the sk98lin driver: | With sk98lin under both 2.6.12 and 2.6.17 I get the following message, | repeated countless times, and finally a hang: [this is copied from | screen on to a sheet a paper and re-typed, beware typos]: | eth0: Adapter failed | eth0: -- ERROR -- | class: Hardware failure | Nr: 0x264 | Msg: unexpected IRQ Status error The bug is still present in 2.6.17 -mm6: | -mm6 does not work with skge and the hardware memory hole. It gave | these messages: | skge eth0: enabling interface | skge :00:0a.0: PCI error cmd=0x117 status=0x22b0 | skge unable to clear error (so ignoring them) | skge eth0: Link is up at 1000 Mbps, full duplex, flow control tx and rx | DHCP never managed to get an IP address. Any idea what to do about this? I don't really have access to the hardware, or know the x86-64 details perhaps Andi Kleen would be of more help. But my suspicion is that the remapping doesn't work for i/o devices because of hardware or BIOS. One simple workaround is to force use of the I/O mmu on the amd64 processor. This has a small performance impact (requires more setup). See Documentation/x86_64/boot-options.txt iommu=force -- Stephen Hemminger [EMAIL PROTECTED] Quis custodiet ipsos custodes? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
