19 Jun, 2019

1 commit

  • Based on 2 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license version 2 as
    published by the free software foundation

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license version 2 as
    published by the free software foundation #

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-only

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

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

    Thomas Gleixner
     

07 Jun, 2018

1 commit

  • One of the more common cases of allocation size calculations is finding
    the size of a structure that has a zero-sized array at the end, along
    with memory for some number of elements for that array. For example:

    struct foo {
    int stuff;
    void *entry[];
    };

    instance = kmalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);

    Instead of leaving these open-coded and prone to type mistakes, we can
    now use the new struct_size() helper:

    instance = kmalloc(struct_size(instance, entry, count), GFP_KERNEL);

    This patch makes the changes for kmalloc()-family (and kvmalloc()-family)
    uses. It was done via automatic conversion with manual review for the
    "CHECKME" non-standard cases noted below, using the following Coccinelle
    script:

    // pkey_cache = kmalloc(sizeof *pkey_cache + tprops->pkey_tbl_len *
    // sizeof *pkey_cache->table, GFP_KERNEL);
    @@
    identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc";
    expression GFP;
    identifier VAR, ELEMENT;
    expression COUNT;
    @@

    - alloc(sizeof(*VAR) + COUNT * sizeof(*VAR->ELEMENT), GFP)
    + alloc(struct_size(VAR, ELEMENT, COUNT), GFP)

    // mr = kzalloc(sizeof(*mr) + m * sizeof(mr->map[0]), GFP_KERNEL);
    @@
    identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc";
    expression GFP;
    identifier VAR, ELEMENT;
    expression COUNT;
    @@

    - alloc(sizeof(*VAR) + COUNT * sizeof(VAR->ELEMENT[0]), GFP)
    + alloc(struct_size(VAR, ELEMENT, COUNT), GFP)

    // Same pattern, but can't trivially locate the trailing element name,
    // or variable name.
    @@
    identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc";
    expression GFP;
    expression SOMETHING, COUNT, ELEMENT;
    @@

    - alloc(sizeof(SOMETHING) + COUNT * sizeof(ELEMENT), GFP)
    + alloc(CHECKME_struct_size(&SOMETHING, ELEMENT, COUNT), GFP)

    Signed-off-by: Kees Cook

    Kees Cook
     

12 Apr, 2018

1 commit

  • UI_SET_LEDBIT ioctl() causes the following KASAN splat when used with
    led > LED_CHARGING:

    [ 1274.663418] BUG: KASAN: slab-out-of-bounds in input_leds_connect+0x611/0x730 [input_leds]
    [ 1274.663426] Write of size 8 at addr ffff88003377b2c0 by task ckb-next-daemon/5128

    This happens because we were writing to the led structure before making
    sure that it exists.

    Reported-by: Tasos Sahanidis
    Tested-by: Tasos Sahanidis
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov

    Dmitry Torokhov
     

25 Jul, 2015

1 commit

  • Devices may declare more LEDs than what is known to input-leds
    (HID does this for some devices). Instead of showing ugly warnings
    on connect and, even worse, oopsing on disconnect, let's simply
    ignore LEDs that are not known to us.

    Reported-and-tested-by: Vlastimil Babka
    Signed-off-by: Dmitry Torokhov

    Dmitry Torokhov
     

12 Jun, 2015

1 commit

  • This change creates a new input handler called "leds" that exports LEDs on input
    devices as standard LED class devices in sysfs and allows controlling their
    state via sysfs or via any of the standard LED triggers. This allows to
    re-purpose and reassign LDEs on the keyboards to represent states other
    than the standard keyboard states (CapsLock, NumLock, etc).

    The old API of controlling input LEDs by writing into /dev/input/eventX
    devices is still present and will take precedence over accessing via LEDs
    subsystem (i.e. it may override state set by a trigger). If input device is
    "grabbed" then requests coming through LED subsystem will be ignored.

    Signed-off-by: Samuel Thibault
    Tested-by: Pavel Machek
    Acked-by: Pavel Machek
    Signed-off-by: Dmitry Torokhov

    Samuel Thibault