24 Aug, 2020

1 commit

  • Replace the existing /* fall through */ comments and its variants with
    the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
    fall-through markings when it is the case.

    [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through

    Signed-off-by: Gustavo A. R. Silva

    Gustavo A. R. Silva
     

24 May, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this module is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

    has been chosen to replace the boilerplate/reference in 18 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190520170858.008906948@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

22 Oct, 2017

1 commit


10 May, 2016

1 commit

  • Stack object "dte_facilities" is allocated in x25_rx_call_request(),
    which is supposed to be initialized in x25_negotiate_facilities.
    However, 5 fields (8 bytes in total) are not initialized. This
    object is then copied to userland via copy_to_user, thus infoleak
    occurs.

    Signed-off-by: Kangjie Lu
    Signed-off-by: David S. Miller

    Kangjie Lu
     

10 Dec, 2013

1 commit


04 Sep, 2013

1 commit

  • This was found with a manual audit and I don't have a reproducer. We
    limit ->calling_len and ->called_len when we get them from
    copy_from_user() in x25_ioctl() so when they come from skb->data then
    we should cap them there as well.

    Signed-off-by: Dan Carpenter
    Signed-off-by: David S. Miller

    Dan Carpenter
     

16 Apr, 2012

1 commit


18 Oct, 2011

1 commit

  • There are multiple locations in the X.25 packet layer where a skb is
    assumed to be of at least a certain size and that all its data is
    currently available at skb->data. These assumptions are not checked,
    hence buffer overreads may occur. Use pskb_may_pull to check these
    minimal size assumptions and ensure that data is available at skb->data
    when necessary, as well as use skb_copy_bits where needed.

    Signed-off-by: Matthew Daley
    Cc: Eric Dumazet
    Cc: Andrew Hendry
    Cc: stable
    Acked-by: Andrew Hendry
    Signed-off-by: David S. Miller

    Matthew Daley
     

31 Mar, 2011

1 commit


08 Feb, 2011

1 commit

  • Originally x25_parse_facilities returned
    -1 for an error
    0 meaning 0 length facilities
    >0 the length of the facilities parsed.

    5ef41308f94dc ("x25: Prevent crashing when parsing bad X.25 facilities") introduced more
    error checking in x25_parse_facilities however used 0 to indicate bad parsing
    a6331d6f9a429 ("memory corruption in X.25 facilities parsing") followed this further for
    DTE facilities, again using 0 for bad parsing.

    The meaning of 0 got confused in the callers.
    If the facilities are messed up we can't determine where the data starts.
    So patch makes all parsing errors return -1 and ensures callers close and don't use the skb further.

    Reported-by: Andy Whitcroft
    Signed-off-by: Andrew Hendry
    Signed-off-by: David S. Miller

    andrew hendry
     

13 Nov, 2010

1 commit

  • Now with improved comma support.

    On parsing malformed X.25 facilities, decrementing the remaining length
    may cause it to underflow. Since the length is an unsigned integer,
    this will result in the loop continuing until the kernel crashes.

    This patch adds checks to ensure decrementing the remaining length does
    not cause it to wrap around.

    Signed-off-by: Dan Rosenberg
    Signed-off-by: David S. Miller

    Dan Rosenberg
     

04 Nov, 2010

1 commit


08 Apr, 2010

2 commits

  • The current X.25 code has some bugs in throughput negotiation:

    1. It does negotiation in all cases, usually there is no need
    2. It incorrectly attempts to negotiate the throughput class in one
    direction only. There are separate throughput classes for input
    and output and if either is negotiated both mist be negotiates.

    This is bug https://bugzilla.kernel.org/show_bug.cgi?id=15681

    This bug was first reported by Daniel Ferenci to the linux-x25 mailing
    list on 6/8/2004, but is still present.

    The current (2.6.34) x.25 code doesn't seem to know that the X.25
    throughput facility includes two values, one for the required
    throughput outbound, one for inbound.

    This causes it to attempt to negotiate throughput 0x0A, which is
    throughput 9600 inbound and the illegal value "0" for inbound
    throughput.

    Because of this some X.25 devices (e.g. Cisco 1600) refuse to connect
    to Linux X.25.

    The following patch fixes this behaviour. Unless the user specifies a
    required throughput it does not attempt to negotiate. If the user
    does not specify a throughput it accepts the suggestion of the remote
    X.25 system. If the user requests a throughput then it validates both
    the input and output throughputs and correctly negotiates them with
    the remote end.

    Signed-off-by: John Hughes
    Tested-by: Andrew Hendry
    Signed-off-by: David S. Miller

    John Hughes
     
  • Here is a patch to stop X.25 examining fields beyond the end of the packet.

    For example, when a simple CALL ACCEPTED was received:

    10 10 0f

    x25_parse_facilities was attempting to decode the FACILITIES field, but this
    packet contains no facilities field.

    Signed-off-by: John Hughes
    Signed-off-by: David S. Miller

    John Hughes
     

29 Jan, 2008

1 commit

  • CHECK net/x25/af_x25.c
    net/x25/af_x25.c:117:46: warning: expensive signed divide
    CHECK net/x25/x25_facilities.c
    net/x25/x25_facilities.c:209:30: warning: expensive signed divide
    CHECK net/x25/x25_in.c
    net/x25/x25_in.c:250:26: warning: expensive signed divide
    CHECK net/x25/x25_proc.c
    net/x25/x25_proc.c:48:11: warning: context imbalance in 'x25_seq_route_start'
    - wrong count at exit
    net/x25/x25_proc.c:72:13: warning: context imbalance in 'x25_seq_route_stop' -
    unexpected unlock
    net/x25/x25_proc.c:112:11: warning: context imbalance in
    'x25_seq_socket_start' - wrong count at exit
    net/x25/x25_proc.c:129:13: warning: context imbalance in 'x25_seq_socket_stop'
    - unexpected unlock
    net/x25/x25_proc.c:190:11: warning: context imbalance in
    'x25_seq_forward_start' - wrong count at exit
    net/x25/x25_proc.c:215:13: warning: context imbalance in
    'x25_seq_forward_stop' - unexpected unlock
    CHECK net/x25/x25_subr.c
    net/x25/x25_subr.c:362:57: warning: expensive signed divide

    Signed-off-by: Eric Dumazet
    Signed-off-by: David S. Miller

    Eric Dumazet
     

11 Feb, 2007

1 commit


09 Jan, 2007

1 commit


22 Mar, 2006

1 commit

  • Allows use of the optional user facility to insert ITU-T
    (http://www.itu.int/ITU-T/) specified DTE facilities in call set-up x25
    packets. This feature is optional; no facilities will be added if the ioctl
    is not used, and call setup packet remains the same as before.

    If the ioctls provided by the patch are used, then a facility marker will be
    added to the x25 packet header so that the called dte address extension
    facility can be differentiated from other types of facilities (as described in
    the ITU-T X.25 recommendation) that are also allowed in the x25 packet header.

    Facility markers are made up of two octets, and may be present in the x25
    packet headers of call-request, incoming call, call accepted, clear request,
    and clear indication packets. The first of the two octets represents the
    facility code field and is set to zero by this patch. The second octet of the
    marker represents the facility parameter field and is set to 0x0F because the
    marker will be inserted before ITU-T type DTE facilities.

    Since according to ITU-T X.25 Recommendation X.25(10/96)- 7.1 "All networks
    will support the facility markers with a facility parameter field set to all
    ones or to 00001111", therefore this patch should work with all x.25 networks.

    While there are many ITU-T DTE facilities, this patch implements only the
    called and calling address extension, with placeholders in the
    x25_dte_facilities structure for the rest of the facilities.

    Testing:

    This patch was tested using a cisco xot router connected on its serial ports
    to an X.25 network, and on its lan ports to a host running an xotd daemon.

    It is also possible to test this patch using an xotd daemon and an x25tap
    patch, where the xotd daemons work back-to-back without actually using an x.25
    network. See www.fyonne.net for details on how to do this.

    Signed-off-by: Shaun Pereira
    Acked-by: Andrew Hendry
    Signed-off-by: Andrew Morton
    Signed-off-by: David S. Miller

    Shaun Pereira
     

23 Jun, 2005

1 commit

  • This patch is a follow up to patch 1 regarding "Selective Sub Address
    matching with call user data". It allows use of the Fast-Select-Acceptance
    optional user facility for X.25.

    This patch just implements fast select with no restriction on response
    (NRR). What this means (according to ITU-T Recomendation 10/96 section
    6.16) is that if in an incoming call packet, the relevant facility bits are
    set for fast-select-NRR, then the called DTE can issue a direct response to
    the incoming packet using a call-accepted packet that contains
    call-user-data. This patch allows such a response.

    The called DTE can also respond with a clear-request packet that contains
    call-user-data. However, this feature is currently not implemented by the
    patch.

    How is Fast Select Acceptance used?
    By default, the system does not allow fast select acceptance (as before).
    To enable a response to fast select acceptance,
    After a listen socket in created and bound as follows
    socket(AF_X25, SOCK_SEQPACKET, 0);
    bind(call_soc, (struct sockaddr *)&locl_addr, sizeof(locl_addr));
    but before a listen system call is made, the following ioctl should be used.
    ioctl(call_soc,SIOCX25CALLACCPTAPPRV);
    Now the listen system call can be made
    listen(call_soc, 4);
    After this, an incoming-call packet will be accepted, but no call-accepted
    packet will be sent back until the following system call is made on the socket
    that accepts the call
    ioctl(vc_soc,SIOCX25SENDCALLACCPT);
    The network (or cisco xot router used for testing here) will allow the
    application server's call-user-data in the call-accepted packet,
    provided the call-request was made with Fast-select NRR.

    Signed-off-by: Shaun Pereira
    Signed-off-by: Andrew Morton
    Signed-off-by: David S. Miller

    Shaun Pereira
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds