These intefaces haven't existed since 2.2.x Signed-off-by: David S. Miller <davem@davemloft.net>
Nobody alive seems to recall when they last were useful. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
Define some constant offsets for CALL_REQUEST based on the description at <http://www.techfest.com/networking/wan/x25plp.htm> and the definition of ROSE as using 10-digit (5-byte) addresses. Use them consistently. Validate all implicit and explicit facilities lengths. Validate the address length byte rather than either trusting or assuming its value. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
When parsing the FAC_NATIONAL_DIGIS facilities field, it's possible for a remote host to provide more digipeaters than expected, resulting in heap corruption. Check against ROSE_MAX_DIGIS to prevent overflows, and abort facilities parsing on failure. Additionally, when parsing the FAC_CCITT_DEST_NSAP and FAC_CCITT_SRC_NSAP facilities fields, a remote host can provide a length of less than 10, resulting in an underflow in a memcpy size, causing a kernel panic due to massive heap corruption. A length of greater than 20 results in a stack overflow of the callsign array. Abort facilities parsing on these invalid length values. Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com> Cc: stable@kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
With previous patch, rose_get_neigh() routine investigates the full list of neighbor nodes until it finds or not an already connected node whether it is called locally or through a level 3 transit frame. If no routes are opened through an adjacent connected node then a classical connect request is attempted. Then there is no more reason for an extra loop such as the one removed by this patch. Signed-off-by: Bernard Pidoux <f6bvp@free.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
FPAC AX25 packet application is using Linux kernel ROSE routing skills in order to connect or send packets to remote stations knowing their ROSE address via a network of interconnected nodes. Each FPAC node has a ROSE routing table that Linux ROSE module is looking at each time a ROSE frame is relayed by the node or when a connect request to a neighbor node is received. A previous patch improved the system time response by looking at already established routes each time the system was looking for a route to relay a frame. If a neighbor node routing the destination address was already connected, then the frame would be sent through him. If not, a connection request would be issued. The present patch extends the same routing capability to a connect request asked by a user locally connected into an FPAC node. Without this patch, a connect request was not well handled unless it was directed to an immediate connected neighbor of the local node. Implemented at a number of ROSE FPAC node stations, the present patch improved dramatically FPAC ROSE routing time response and efficiency. Signed-off-by: Bernard Pidoux <f6bvp@free.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
Conflicts: drivers/net/qlcnic/qlcnic_init.c net/ipv4/ip_output.c
Change "return (EXPR);" to "return EXPR;" return is not a function, parentheses are not required. Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Just use explicit casts, since we really can't change the types of structures exported to userspace which have been around for 15 years or so. Reported-by: Dan Rosenberg <dan.j.rosenberg@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>