1. 07 Jun, 2016 40 commits
    • Marco Angaroni's avatar
      ipvs: correct initial offset of Call-ID header search in SIP persistence engine · 049c18da
      Marco Angaroni authored
      commit 7617a24f upstream.
      
      The IPVS SIP persistence engine is not able to parse the SIP header
      "Call-ID" when such header is inserted in the first positions of
      the SIP message.
      
      When IPVS is configured with "--pe sip" option, like for example:
      ipvsadm -A -u 1.2.3.4:5060 -s rr --pe sip -p 120 -o
      some particular messages (see below for details) do not create entries
      in the connection template table, which can be listed with:
      ipvsadm -Lcn --persistent-conn
      
      Problematic SIP messages are SIP responses having "Call-ID" header
      positioned just after message first line:
      SIP/2.0 200 OK
      [Call-ID header here]
      [rest of the headers]
      
      When "Call-ID" header is positioned down (after a few other headers)
      it is correctly recognized.
      
      This is due to the data offset used in get_callid function call inside
      ip_vs_pe_sip.c file: since dptr already points to the start of the
      SIP message, the value of dataoff should be initially 0.
      Otherwise the header is searched starting from some bytes after the
      first character of the SIP message.
      
      Fixes: 758ff033 ("IPVS: sip persistence engine")
      Signed-off-by: default avatarMarco Angaroni <marcoangaroni@gmail.com>
      Acked-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      049c18da
    • Paolo Bonzini's avatar
      compiler-gcc: disable -ftracer for __noclone functions · 5d814ad8
      Paolo Bonzini authored
      commit 95272c29 upstream.
      
      -ftracer can duplicate asm blocks causing compilation to fail in
      noclone functions.  For example, KVM declares a global variable
      in an asm like
      
          asm("2: ... \n
               .pushsection data \n
               .global vmx_return \n
               vmx_return: .long 2b");
      
      and -ftracer causes a double declaration.
      
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: stable@vger.kernel.org
      Cc: kvm@vger.kernel.org
      Reported-by: default avatarLinda Walsh <lkml@tlinx.org>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      5d814ad8
    • Pali Rohár's avatar
      ARM: OMAP3: Add cpuidle parameters table for omap3430 · 26898db6
      Pali Rohár authored
      commit 98f42221 upstream.
      
      Based on CPU type choose generic omap3 or omap3430 specific cpuidle
      parameters. Parameters for omap3430 were measured on Nokia N900 device and
      added by commit 5a1b1d3a ("OMAP3: RX-51: Pass cpu idle parameters")
      which were later removed by commit 231900af ("ARM: OMAP3: cpuidle -
      remove rx51 cpuidle parameters table") due to huge code complexity.
      
      This patch brings cpuidle parameters for omap3430 devices again, but uses
      simple condition based on CPU type.
      
      Fixes: 231900af ("ARM: OMAP3: cpuidle - remove rx51 cpuidle
      parameters table")
      Signed-off-by: default avatarPali Rohr <pali.rohar@gmail.com>
      Acked-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      26898db6
    • Borislav Petkov's avatar
      perf stat: Document --detailed option · ab306782
      Borislav Petkov authored
      commit f594bae0 upstream.
      
      I'm surprised this remained undocumented since at least 2011. And it is
      actually a very useful switch, as Steve and I came to realize recently.
      
      Add the text from
      
        2cba3ffb ("perf stat: Add -d -d and -d -d -d options to show more CPU events")
      
      which added the incrementing aspect to -d.
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Davidlohr Bueso <dbueso@suse.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mel Gorman <mgorman@suse.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 2cba3ffb ("perf stat: Add -d -d and -d -d -d options to show more CPU events")
      Link: http://lkml.kernel.org/r/1457347294-32546-1-git-send-email-bp@alien8.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      ab306782
    • Vitaly Kuznetsov's avatar
      Drivers: hv: vmbus: prevent cpu offlining on newer hypervisors · 70415182
      Vitaly Kuznetsov authored
      commit e513229b upstream.
      
      When an SMP Hyper-V guest is running on top of 2012R2 Server and secondary
      cpus are sent offline (with echo 0 > /sys/devices/system/cpu/cpu$cpu/online)
      the system freeze is observed. This happens due to the fact that on newer
      hypervisors (Win8, WS2012R2, ...) vmbus channel handlers are distributed
      across all cpus (see init_vp_index() function in drivers/hv/channel_mgmt.c)
      and on cpu offlining nobody reassigns them to CPU0. Prevent cpu offlining
      when vmbus is loaded until the issue is fixed host-side.
      
      This patch also disables hibernation but it is OK as it is also broken (MCE
      error is hit on resume). Suspend still works.
      
      Tested with WS2008R2 and WS2012R2.
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      [ 3chas3@gmail.com: rebase to 3.14-stable ]
      Signed-off-by: default avatarChas Williams <3chas3@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      70415182
    • Vasily Kulikov's avatar
      include/linux/poison.h: fix LIST_POISON{1,2} offset · df1da5a5
      Vasily Kulikov authored
      commit 8a5e5e02 upstream.
      
      Poison pointer values should be small enough to find a room in
      non-mmap'able/hardly-mmap'able space.  E.g.  on x86 "poison pointer space"
      is located starting from 0x0.  Given unprivileged users cannot mmap
      anything below mmap_min_addr, it should be safe to use poison pointers
      lower than mmap_min_addr.
      
      The current poison pointer values of LIST_POISON{1,2} might be too big for
      mmap_min_addr values equal or less than 1 MB (common case, e.g.  Ubuntu
      uses only 0x10000).  There is little point to use such a big value given
      the "poison pointer space" below 1 MB is not yet exhausted.  Changing it
      to a smaller value solves the problem for small mmap_min_addr setups.
      
      The values are suggested by Solar Designer:
      http://www.openwall.com/lists/oss-security/2015/05/02/6Signed-off-by: default avatarVasily Kulikov <segoon@openwall.com>
      Cc: Solar Designer <solar@openwall.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      df1da5a5
    • Michael Hennerich's avatar
      drivers/misc/ad525x_dpot: AD5274 fix RDAC read back errors · 310c45d1
      Michael Hennerich authored
      commit f3df53e4 upstream.
      
      Fix RDAC read back errors caused by a typo. Value must shift by 2.
      
      Fixes: a4bd3949 ("drivers/misc/ad525x_dpot.c: new features")
      Signed-off-by: default avatarMichael Hennerich <michael.hennerich@analog.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      310c45d1
    • Geert Uytterhoeven's avatar
      rtc: vr41xx: Wire up alarm_irq_enable · e35d9831
      Geert Uytterhoeven authored
      commit a25f4a95 upstream.
      
      drivers/rtc/rtc-vr41xx.c:229: warning: ‘vr41xx_rtc_alarm_irq_enable’ defined but not used
      
      Apparently the conversion to alarm_irq_enable forgot to wire up the
      callback.
      
      Fixes: 16380c15 ("RTC: Convert rtc drivers to use the alarm_irq_enable method")
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      e35d9831
    • Ben Hutchings's avatar
      misc/bmp085: Enable building as a module · 8e806835
      Ben Hutchings authored
      commit 50e6315d upstream.
      
      Commit 985087db 'misc: add support for bmp18x chips to the bmp085
      driver' changed the BMP085 config symbol to a boolean.  I see no
      reason why the shared code cannot be built as a module, so change it
      back to tristate.
      
      Fixes: 985087db ("misc: add support for bmp18x chips to the bmp085 driver")
      Cc: Eric Andersson <eric.andersson@unixphere.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      8e806835
    • Sushaanth Srirangapathi's avatar
      fbdev: da8xx-fb: fix videomodes of lcd panels · 78d64c69
      Sushaanth Srirangapathi authored
      commit 713fced8 upstream.
      
      Commit 028cd86b ("video: da8xx-fb: fix the polarities of the
      hsync/vsync pulse") fixes polarities of HSYNC/VSYNC pulse but
      forgot to update known_lcd_panels[] which had sync values
      according to old logic. This breaks LCD at least on DA850 EVM.
      
      This patch fixes this issue and I have tested this for panel
      "Sharp_LK043T1DG01" using DA850 EVM board.
      
      Fixes: 028cd86b ("video: da8xx-fb: fix the polarities of the hsync/vsync pulse")
      Signed-off-by: default avatarSushaanth Srirangapathi <sushaanth.s@ti.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      78d64c69
    • Arnd Bergmann's avatar
      paride: make 'verbose' parameter an 'int' again · 226a8ce3
      Arnd Bergmann authored
      commit dec63a4d upstream.
      
      gcc-6.0 found an ancient bug in the paride driver, which had a
      "module_param(verbose, bool, 0);" since before 2.6.12, but actually uses
      it to accept '0', '1' or '2' as arguments:
      
        drivers/block/paride/pd.c: In function 'pd_init_dev_parms':
        drivers/block/paride/pd.c:298:29: warning: comparison of constant '1' with boolean expression is always false [-Wbool-compare]
         #define DBMSG(msg) ((verbose>1)?(msg):NULL)
      
      In 2012, Rusty did a cleanup patch that also changed the type of the
      variable to 'bool', which introduced what is now a gcc warning.
      
      This changes the type back to 'int' and adapts the module_param() line
      instead, so it should work as documented in case anyone ever cares about
      running the ancient driver with debugging.
      
      Fixes: 90ab5ee9 ("module_param: make bool parameters really bool (drivers & misc)")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Rusty Russell <rusty@rustcorp.com.au>
      Cc: Tim Waugh <tim@cyberelk.net>
      Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
      Cc: Jens Axboe <axboe@fb.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      226a8ce3
    • Ignat Korchagin's avatar
      USB: usbip: fix potential out-of-bounds write · 378175d0
      Ignat Korchagin authored
      commit b348d7dd upstream.
      
      Fix potential out-of-bounds write to urb->transfer_buffer
      usbip handles network communication directly in the kernel. When receiving a
      packet from its peer, usbip code parses headers according to protocol. As
      part of this parsing urb->actual_length is filled. Since the input for
      urb->actual_length comes from the network, it should be treated as untrusted.
      Any entity controlling the network may put any value in the input and the
      preallocated urb->transfer_buffer may not be large enough to hold the data.
      Thus, the malicious entity is able to write arbitrary data to kernel memory.
      Signed-off-by: default avatarIgnat Korchagin <ignat.korchagin@gmail.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      378175d0
    • Roman Pen's avatar
      workqueue: fix ghost PENDING flag while doing MQ IO · 8a872b18
      Roman Pen authored
      commit 346c09f8 upstream.
      
      The bug in a workqueue leads to a stalled IO request in MQ ctx->rq_list
      with the following backtrace:
      
      [  601.347452] INFO: task kworker/u129:5:1636 blocked for more than 120 seconds.
      [  601.347574]       Tainted: G           O    4.4.5-1-storage+ #6
      [  601.347651] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [  601.348142] kworker/u129:5  D ffff880803077988     0  1636      2 0x00000000
      [  601.348519] Workqueue: ibnbd_server_fileio_wq ibnbd_dev_file_submit_io_worker [ibnbd_server]
      [  601.348999]  ffff880803077988 ffff88080466b900 ffff8808033f9c80 ffff880803078000
      [  601.349662]  ffff880807c95000 7fffffffffffffff ffffffff815b0920 ffff880803077ad0
      [  601.350333]  ffff8808030779a0 ffffffff815b01d5 0000000000000000 ffff880803077a38
      [  601.350965] Call Trace:
      [  601.351203]  [<ffffffff815b0920>] ? bit_wait+0x60/0x60
      [  601.351444]  [<ffffffff815b01d5>] schedule+0x35/0x80
      [  601.351709]  [<ffffffff815b2dd2>] schedule_timeout+0x192/0x230
      [  601.351958]  [<ffffffff812d43f7>] ? blk_flush_plug_list+0xc7/0x220
      [  601.352208]  [<ffffffff810bd737>] ? ktime_get+0x37/0xa0
      [  601.352446]  [<ffffffff815b0920>] ? bit_wait+0x60/0x60
      [  601.352688]  [<ffffffff815af784>] io_schedule_timeout+0xa4/0x110
      [  601.352951]  [<ffffffff815b3a4e>] ? _raw_spin_unlock_irqrestore+0xe/0x10
      [  601.353196]  [<ffffffff815b093b>] bit_wait_io+0x1b/0x70
      [  601.353440]  [<ffffffff815b056d>] __wait_on_bit+0x5d/0x90
      [  601.353689]  [<ffffffff81127bd0>] wait_on_page_bit+0xc0/0xd0
      [  601.353958]  [<ffffffff81096db0>] ? autoremove_wake_function+0x40/0x40
      [  601.354200]  [<ffffffff81127cc4>] __filemap_fdatawait_range+0xe4/0x140
      [  601.354441]  [<ffffffff81127d34>] filemap_fdatawait_range+0x14/0x30
      [  601.354688]  [<ffffffff81129a9f>] filemap_write_and_wait_range+0x3f/0x70
      [  601.354932]  [<ffffffff811ced3b>] blkdev_fsync+0x1b/0x50
      [  601.355193]  [<ffffffff811c82d9>] vfs_fsync_range+0x49/0xa0
      [  601.355432]  [<ffffffff811cf45a>] blkdev_write_iter+0xca/0x100
      [  601.355679]  [<ffffffff81197b1a>] __vfs_write+0xaa/0xe0
      [  601.355925]  [<ffffffff81198379>] vfs_write+0xa9/0x1a0
      [  601.356164]  [<ffffffff811c59d8>] kernel_write+0x38/0x50
      
      The underlying device is a null_blk, with default parameters:
      
        queue_mode    = MQ
        submit_queues = 1
      
      Verification that nullb0 has something inflight:
      
      root@pserver8:~# cat /sys/block/nullb0/inflight
             0        1
      root@pserver8:~# find /sys/block/nullb0/mq/0/cpu* -name rq_list -print -exec cat {} \;
      ...
      /sys/block/nullb0/mq/0/cpu2/rq_list
      CTX pending:
              ffff8838038e2400
      ...
      
      During debug it became clear that stalled request is always inserted in
      the rq_list from the following path:
      
         save_stack_trace_tsk + 34
         blk_mq_insert_requests + 231
         blk_mq_flush_plug_list + 281
         blk_flush_plug_list + 199
         wait_on_page_bit + 192
         __filemap_fdatawait_range + 228
         filemap_fdatawait_range + 20
         filemap_write_and_wait_range + 63
         blkdev_fsync + 27
         vfs_fsync_range + 73
         blkdev_write_iter + 202
         __vfs_write + 170
         vfs_write + 169
         kernel_write + 56
      
      So blk_flush_plug_list() was called with from_schedule == true.
      
      If from_schedule is true, that means that finally blk_mq_insert_requests()
      offloads execution of __blk_mq_run_hw_queue() and uses kblockd workqueue,
      i.e. it calls kblockd_schedule_delayed_work_on().
      
      That means, that we race with another CPU, which is about to execute
      __blk_mq_run_hw_queue() work.
      
      Further debugging shows the following traces from different CPUs:
      
        CPU#0                                  CPU#1
        ----------------------------------     -------------------------------
        reqeust A inserted
        STORE hctx->ctx_map[0] bit marked
        kblockd_schedule...() returns 1
        <schedule to kblockd workqueue>
                                               request B inserted
                                               STORE hctx->ctx_map[1] bit marked
                                               kblockd_schedule...() returns 0
        *** WORK PENDING bit is cleared ***
        flush_busy_ctxs() is executed, but
        bit 1, set by CPU#1, is not observed
      
      As a result request B pended forever.
      
      This behaviour can be explained by speculative LOAD of hctx->ctx_map on
      CPU#0, which is reordered with clear of PENDING bit and executed _before_
      actual STORE of bit 1 on CPU#1.
      
      The proper fix is an explicit full barrier <mfence>, which guarantees
      that clear of PENDING bit is to be executed before all possible
      speculative LOADS or STORES inside actual work function.
      Signed-off-by: default avatarRoman Pen <roman.penyaev@profitbricks.com>
      Cc: Gioh Kim <gi-oh.kim@profitbricks.com>
      Cc: Michael Wang <yun.wang@profitbricks.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: linux-block@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      8a872b18
    • Laszlo Ersek's avatar
      efi: Fix out-of-bounds read in variable_matches() · e2d8aa41
      Laszlo Ersek authored
      commit 630ba0cc upstream.
      
      The variable_matches() function can currently read "var_name[len]", for
      example when:
      
       - var_name[0] == 'a',
       - len == 1
       - match_name points to the NUL-terminated string "ab".
      
      This function is supposed to accept "var_name" inputs that are not
      NUL-terminated (hence the "len" parameter"). Document the function, and
      access "var_name[*match]" only if "*match" is smaller than "len".
      Reported-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Matthew Garrett <mjg59@coreos.com>
      Cc: Jason Andryuk <jandryuk@gmail.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: <stable@vger.kernel.org> # v3.10+
      Link: http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/86906Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      e2d8aa41
    • Arnd Bergmann's avatar
      ASoC: s3c24xx: use const snd_soc_component_driver pointer · fba8a3ec
      Arnd Bergmann authored
      commit ba4bc32e upstream.
      
      An older patch to convert the API in the s3c i2s driver
      ended up passing a const pointer into a function that takes
      a non-const pointer, so we now get a warning:
      
      sound/soc/samsung/s3c2412-i2s.c: In function 's3c2412_iis_dev_probe':
      sound/soc/samsung/s3c2412-i2s.c:172:9: error: passing argument 3 of 's3c_i2sv2_register_component' discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
      
      However, the s3c_i2sv2_register_component() function again
      passes the pointer into another function taking a const, so
      we just need to change its prototype.
      
      Fixes: eca3b01d ("ASoC: switch over to use snd_soc_register_component() on s3c i2s")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      fba8a3ec
    • Tony Luck's avatar
      EDAC: i7core, sb_edac: Don't return NOTIFY_BAD from mce_decoder callback · 8d418eb3
      Tony Luck authored
      commit c4fc1956 upstream.
      
      Both of these drivers can return NOTIFY_BAD, but this terminates
      processing other callbacks that were registered later on the chain.
      Since the driver did nothing to log the error it seems wrong to prevent
      other interested parties from seeing it. E.g. neither of them had even
      bothered to check the type of the error to see if it was a memory error
      before the return NOTIFY_BAD.
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      Acked-by: default avatarAristeu Rozanski <aris@redhat.com>
      Acked-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Cc: <stable@vger.kernel.org>
      Link: http://lkml.kernel.org/r/72937355dd92318d2630979666063f8a2853495b.1461864507.git.tony.luck@intel.comSigned-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      8d418eb3
    • Michael Ellerman's avatar
      i2c: cpm: Fix build break due to incompatible pointer types · faf35c26
      Michael Ellerman authored
      commit 609d5a1b upstream.
      
      Since commit ea8daa7b ("kbuild: Add option to turn incompatible
      pointer check into error"), assignments from an incompatible pointer
      types have become a hard error, eg:
      
        drivers/i2c/busses/i2c-cpm.c:545:91: error: passing argument 3 of
        'dma_alloc_coherent' from incompatible pointer type
      
      Fix the build break by converting txdma & rxdma to dma_addr_t.
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Cc: stable@kernel.org
      Fixes: ea8daa7bSigned-off-by: default avatarWilly Tarreau <w@1wt.eu>
      faf35c26
    • Vladis Dronov's avatar
      Input: gtco - fix crash on detecting device without endpoints · adaad9d8
      Vladis Dronov authored
      commit 162f98de upstream.
      
      The gtco driver expects at least one valid endpoint. If given malicious
      descriptors that specify 0 for the number of endpoints, it will crash in
      the probe function. Ensure there is at least one endpoint on the interface
      before using it.
      
      Also let's fix a minor coding style issue.
      
      The full correct report of this issue can be found in the public
      Red Hat Bugzilla:
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1283385Reported-by: default avatarRalf Spenneberg <ralf@spenneberg.net>
      Signed-off-by: default avatarVladis Dronov <vdronov@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      adaad9d8
    • Dmitry Ivanov's avatar
      nl80211: check netlink protocol in socket release notification · 3af67b1b
      Dmitry Ivanov authored
      commit 8f815cdd upstream.
      
      A non-privileged user can create a netlink socket with the same port_id as
      used by an existing open nl80211 netlink socket (e.g. as used by a hostapd
      process) with a different protocol number.
      
      Closing this socket will then lead to the notification going to nl80211's
      socket release notification handler, and possibly cause an action such as
      removing a virtual interface.
      
      Fix this issue by checking that the netlink protocol is NETLINK_GENERIC.
      Since generic netlink has no notifier chain of its own, we can't fix the
      problem more generically.
      
      Fixes: 026331c4 ("cfg80211/mac80211: allow registering for and sending action frames")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Ivanov <dima@ubnt.com>
      [rewrite commit message]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      3af67b1b
    • Herbert Xu's avatar
      crypto: gcm - Fix rfc4543 decryption crash · b0b53578
      Herbert Xu authored
      This bug has already bee fixed upstream since 4.2.  However, it
      was fixed during the AEAD conversion so no fix was backported to
      the older kernels.
      
      When we do an RFC 4543 decryption, we will end up writing the
      ICV beyond the end of the dst buffer.  This should lead to a
      crash but for some reason it was never noticed.
      
      This patch fixes it by only writing back the ICV for encryption.
      
      Fixes: d733ac90 ("crypto: gcm - fix rfc4543 to handle async...")
      Reported-by: default avatarPatrick Meyer <patrick.meyer@vasgard.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      b0b53578
    • Robert Dobrowolski's avatar
      usb: hcd: out of bounds access in for_each_companion · 7fbd6329
      Robert Dobrowolski authored
      commit e86103a7 upstream.
      
      On BXT platform Host Controller and Device Controller figure as
      same PCI device but with different device function. HCD should
      not pass data to Device Controller but only to Host Controllers.
      Checking if companion device is Host Controller, otherwise skip.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarRobert Dobrowolski <robert.dobrowolski@linux.intel.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      7fbd6329
    • Lu Baolu's avatar
      usb: xhci: fix wild pointers in xhci_mem_cleanup · e1d54087
      Lu Baolu authored
      commit 71504062 upstream.
      
      This patch fixes some wild pointers produced by xhci_mem_cleanup.
      These wild pointers will cause system crash if xhci_mem_cleanup()
      is called twice.
      Reported-and-tested-by: default avatarPengcheng Li <lpc.li@hisilicon.com>
      Signed-off-by: default avatarLu Baolu <baolu.lu@linux.intel.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [wt: struct xhci_hcd has no ext_caps members in 3.10 ]
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      e1d54087
    • Vladis Dronov's avatar
      usbvision: fix crash on detecting device with invalid configuration · 87e4617a
      Vladis Dronov authored
      commit fa52bd50 upstream.
      
      The usbvision driver crashes when a specially crafted usb device with invalid
      number of interfaces or endpoints is detected. This fix adds checks that the
      device has proper configuration expected by the driver.
      Reported-by: default avatarRalf Spenneberg <ralf@spenneberg.net>
      Signed-off-by: default avatarVladis Dronov <vdronov@redhat.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      87e4617a
    • Alexey Khoroshilov's avatar
      usbvision: fix leak of usb_dev on failure paths in usbvision_probe() · c5b5d09d
      Alexey Khoroshilov authored
      commit afd270d1 upstream.
      
      There is no usb_put_dev() on failure paths in usbvision_probe().
      
      Found by Linux Driver Verification project (linuxtesting.org).
      Signed-off-by: default avatarAlexey Khoroshilov <khoroshilov@ispras.ru>
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      c5b5d09d
    • Alexey Khoroshilov's avatar
      usbvision-video: fix memory leak of alt_max_pkt_size · 6645b827
      Alexey Khoroshilov authored
      commit 090c65b6 upstream.
      
      1. usbvision->alt_max_pkt_size is not deallocated anywhere.
      2. if allocation of usbvision->alt_max_pkt_size fails,
      there is no proper deallocation of already acquired resources.
      The patch adds kfree(usbvision->alt_max_pkt_size) to
      usbvision_release() as soon as other deallocations happen there.
      It calls usbvision_release() if allocation of
      usbvision->alt_max_pkt_size fails as soon as usbvision_release()
      is safe to work with incompletely initialized usbvision structure.
      Found by Linux Driver Verification project (linuxtesting.org).
      Signed-off-by: default avatarAlexey Khoroshilov <khoroshilov@ispras.ru>
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      6645b827
    • Nicolai Hhnle's avatar
      drm/radeon: hold reference to fences in radeon_sa_bo_new (3.17 and older) · f839050d
      Nicolai Hhnle authored
      [Backport of upstream commit f6ff4f67, with
       an additional NULL pointer guard that is required for kernels 3.17 and older.
      
       To be precise, any kernel that does *not* have commit 954605ca "drm/radeon:
       use common fence implementation for fences, v4" requires this additional
       NULL pointer guard.]
      
      An arbitrary amount of time can pass between spin_unlock and
      radeon_fence_wait_any, so we need to ensure that nobody frees the
      fences from under us.
      
      Based on the analogous fix for amdgpu.
      Signed-off-by: default avatarNicolai Hähnle <nicolai.haehnle@amd.com>
      Reviewed-by: Christian König <christian.koenig@amd.com> (v1 + fix)
      Tested-by: default avatarLutz Euler <lutz.euler@freenet.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      f839050d
    • Alan Stern's avatar
      HID: usbhid: fix inconsistent reset/resume/reset-resume behavior · 7ed849b9
      Alan Stern authored
      commit 972e6a99 upstream.
      
      The usbhid driver has inconsistently duplicated code in its post-reset,
      resume, and reset-resume pathways.
      
      	reset-resume doesn't check HID_STARTED before trying to
      	restart the I/O queues.
      
      	resume fails to clear the HID_SUSPENDED flag if HID_STARTED
      	isn't set.
      
      	resume calls usbhid_restart_queues() with usbhid->lock held
      	and the others call it without holding the lock.
      
      The first item in particular causes a problem following a reset-resume
      if the driver hasn't started up its I/O.  URB submission fails because
      usbhid->urbin is NULL, and this triggers an unending reset-retry loop.
      
      This patch fixes the problem by creating a new subroutine,
      hid_restart_io(), to carry out all the common activities.  It also
      adds some checks that were missing in the original code:
      
      	After a reset, there's no need to clear any halted endpoints.
      
      	After a resume, if a reset is pending there's no need to
      	restart any I/O until the reset is finished.
      
      	After a resume, if the interrupt-IN endpoint is halted there's
      	no need to submit the input URB until the halt has been
      	cleared.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarDaniel Fraga <fragabr@gmail.com>
      Tested-by: default avatarDaniel Fraga <fragabr@gmail.com>
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      7ed849b9
    • Theodore Ts'o's avatar
      ext4: add lockdep annotations for i_data_sem · 6a2ba9c0
      Theodore Ts'o authored
      commit daf647d2 upstream.
      
      With the internal Quota feature, mke2fs creates empty quota inodes and
      quota usage tracking is enabled as soon as the file system is mounted.
      Since quotacheck is no longer preallocating all of the blocks in the
      quota inode that are likely needed to be written to, we are now seeing
      a lockdep false positive caused by needing to allocate a quota block
      from inside ext4_map_blocks(), while holding i_data_sem for a data
      inode.  This results in this complaint:
      
        Possible unsafe locking scenario:
      
              CPU0                    CPU1
              ----                    ----
         lock(&ei->i_data_sem);
                                      lock(&s->s_dquot.dqio_mutex);
                                      lock(&ei->i_data_sem);
         lock(&s->s_dquot.dqio_mutex);
      
      Google-Bug-Id: 27907753
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      6a2ba9c0
    • Yoshihiro Shimoda's avatar
      usb: renesas_usbhs: disable TX IRQ before starting TX DMAC transfer · 4407936b
      Yoshihiro Shimoda authored
      commit 6490865c upstream.
      
      This patch adds a code to surely disable TX IRQ of the pipe before
      starting TX DMAC transfer. Otherwise, a lot of unnecessary TX IRQs
      may happen in rare cases when DMAC is used.
      
      Fixes: e73a9891 ("usb: renesas_usbhs: add DMAEngine support")
      Cc: <stable@vger.kernel.org> # v3.1+
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      4407936b
    • Yoshihiro Shimoda's avatar
      usb: renesas_usbhs: avoid NULL pointer derefernce in usbhsf_pkt_handler() · 5a6df60e
      Yoshihiro Shimoda authored
      commit 894f2fc4 upstream.
      
      When unexpected situation happened (e.g. tx/rx irq happened while
      DMAC is used), the usbhsf_pkt_handler() was possible to cause NULL
      pointer dereference like the followings:
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      pgd = c0004000
      [00000000] *pgd=00000000
      Internal error: Oops: 80000007 [#1] SMP ARM
      Modules linked in: usb_f_acm u_serial g_serial libcomposite
      CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.5.0-rc6-00842-gac57066-dirty #63
      Hardware name: Generic R8A7790 (Flattened Device Tree)
      task: c0729c00 ti: c0724000 task.ti: c0724000
      PC is at 0x0
      LR is at usbhsf_pkt_handler+0xac/0x118
      pc : [<00000000>]    lr : [<c03257e0>]    psr: 60000193
      sp : c0725db8  ip : 00000000  fp : c0725df4
      r10: 00000001  r9 : 00000193  r8 : ef3ccab4
      r7 : ef3cca10  r6 : eea4586c  r5 : 00000000  r4 : ef19ceb4
      r3 : 00000000  r2 : 0000009c  r1 : c0725dc4  r0 : ef19ceb4
      
      This patch adds a condition to avoid the dereference.
      
      Fixes: e73a9891 ("usb: renesas_usbhs: add DMAEngine support")
      Cc: <stable@vger.kernel.org> # v3.1+
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      5a6df60e
    • Thadeu Lima de Souza Cascardo's avatar
      ip6_tunnel: set rtnl_link_ops before calling register_netdevice · d840a0cb
      Thadeu Lima de Souza Cascardo authored
      commit b6ee376c upstream.
      
      When creating an ip6tnl tunnel with ip tunnel, rtnl_link_ops is not set
      before ip6_tnl_create2 is called. When register_netdevice is called, there
      is no linkinfo attribute in the NEWLINK message because of that.
      
      Setting rtnl_link_ops before calling register_netdevice fixes that.
      
      Fixes: 0b112457 ("ip6tnl: add support of link creation via rtnl")
      Signed-off-by: default avatarThadeu Lima de Souza Cascardo <cascardo@redhat.com>
      Acked-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      d840a0cb
    • Haishuang Yan's avatar
      ipv6: l2tp: fix a potential issue in l2tp_ip6_recv · 0ad91c67
      Haishuang Yan authored
      commit be447f30 upstream.
      
      pskb_may_pull() can change skb->data, so we have to load ptr/optr at the
      right place.
      Signed-off-by: default avatarHaishuang Yan <yanhaishuang@cmss.chinamobile.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      0ad91c67
    • Haishuang Yan's avatar
      ipv4: l2tp: fix a potential issue in l2tp_ip_recv · e8bf435f
      Haishuang Yan authored
      commit 5745b823 upstream.
      
      pskb_may_pull() can change skb->data, so we have to load ptr/optr at the
      right place.
      Signed-off-by: default avatarHaishuang Yan <yanhaishuang@cmss.chinamobile.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      e8bf435f
    • Bjrn Mork's avatar
      qmi_wwan: add "D-Link DWM-221 B1" device id · c75e78a4
      Bjrn Mork authored
      commit e84810c7 upstream.
      
      Thomas reports:
      "Windows:
      
      00 diagnostics
      01 modem
      02 at-port
      03 nmea
      04 nic
      
      Linux:
      
      T:  Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  4 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=2001 ProdID=7e19 Rev=02.32
      S:  Manufacturer=Mobile Connect
      S:  Product=Mobile Connect
      S:  SerialNumber=0123456789ABCDEF
      C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
      I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
      I:  If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage"
      Reported-by: default avatarThomas Schfer <tschaefer@t-online.de>
      Signed-off-by: default avatarBjrn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      c75e78a4
    • Guillaume Nault's avatar
      ppp: take reference on channels netns · c57d15c3
      Guillaume Nault authored
      commit 1f461dcd upstream.
      
      Let channels hold a reference on their network namespace.
      Some channel types, like ppp_async and ppp_synctty, can have their
      userspace controller running in a different namespace. Therefore they
      can't rely on them to preclude their netns from being removed from
      under them.
      
      ==================================================================
      BUG: KASAN: use-after-free in ppp_unregister_channel+0x372/0x3a0 at
      addr ffff880064e217e0
      Read of size 8 by task syz-executor/11581
      =============================================================================
      BUG net_namespace (Not tainted): kasan: bad access detected
      -----------------------------------------------------------------------------
      
      Disabling lock debugging due to kernel taint
      INFO: Allocated in copy_net_ns+0x6b/0x1a0 age=92569 cpu=3 pid=6906
      [<      none      >] ___slab_alloc+0x4c7/0x500 kernel/mm/slub.c:2440
      [<      none      >] __slab_alloc+0x4c/0x90 kernel/mm/slub.c:2469
      [<     inline     >] slab_alloc_node kernel/mm/slub.c:2532
      [<     inline     >] slab_alloc kernel/mm/slub.c:2574
      [<      none      >] kmem_cache_alloc+0x23a/0x2b0 kernel/mm/slub.c:2579
      [<     inline     >] kmem_cache_zalloc kernel/include/linux/slab.h:597
      [<     inline     >] net_alloc kernel/net/core/net_namespace.c:325
      [<      none      >] copy_net_ns+0x6b/0x1a0 kernel/net/core/net_namespace.c:360
      [<      none      >] create_new_namespaces+0x2f6/0x610 kernel/kernel/nsproxy.c:95
      [<      none      >] copy_namespaces+0x297/0x320 kernel/kernel/nsproxy.c:150
      [<      none      >] copy_process.part.35+0x1bf4/0x5760 kernel/kernel/fork.c:1451
      [<     inline     >] copy_process kernel/kernel/fork.c:1274
      [<      none      >] _do_fork+0x1bc/0xcb0 kernel/kernel/fork.c:1723
      [<     inline     >] SYSC_clone kernel/kernel/fork.c:1832
      [<      none      >] SyS_clone+0x37/0x50 kernel/kernel/fork.c:1826
      [<      none      >] entry_SYSCALL_64_fastpath+0x16/0x7a kernel/arch/x86/entry/entry_64.S:185
      
      INFO: Freed in net_drop_ns+0x67/0x80 age=575 cpu=2 pid=2631
      [<      none      >] __slab_free+0x1fc/0x320 kernel/mm/slub.c:2650
      [<     inline     >] slab_free kernel/mm/slub.c:2805
      [<      none      >] kmem_cache_free+0x2a0/0x330 kernel/mm/slub.c:2814
      [<     inline     >] net_free kernel/net/core/net_namespace.c:341
      [<      none      >] net_drop_ns+0x67/0x80 kernel/net/core/net_namespace.c:348
      [<      none      >] cleanup_net+0x4e5/0x600 kernel/net/core/net_namespace.c:448
      [<      none      >] process_one_work+0x794/0x1440 kernel/kernel/workqueue.c:2036
      [<      none      >] worker_thread+0xdb/0xfc0 kernel/kernel/workqueue.c:2170
      [<      none      >] kthread+0x23f/0x2d0 kernel/drivers/block/aoe/aoecmd.c:1303
      [<      none      >] ret_from_fork+0x3f/0x70 kernel/arch/x86/entry/entry_64.S:468
      INFO: Slab 0xffffea0001938800 objects=3 used=0 fp=0xffff880064e20000
      flags=0x5fffc0000004080
      INFO: Object 0xffff880064e20000 @offset=0 fp=0xffff880064e24200
      
      CPU: 1 PID: 11581 Comm: syz-executor Tainted: G    B           4.4.0+
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
      rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
       00000000ffffffff ffff8800662c7790 ffffffff8292049d ffff88003e36a300
       ffff880064e20000 ffff880064e20000 ffff8800662c77c0 ffffffff816f2054
       ffff88003e36a300 ffffea0001938800 ffff880064e20000 0000000000000000
      Call Trace:
       [<     inline     >] __dump_stack kernel/lib/dump_stack.c:15
       [<ffffffff8292049d>] dump_stack+0x6f/0xa2 kernel/lib/dump_stack.c:50
       [<ffffffff816f2054>] print_trailer+0xf4/0x150 kernel/mm/slub.c:654
       [<ffffffff816f875f>] object_err+0x2f/0x40 kernel/mm/slub.c:661
       [<     inline     >] print_address_description kernel/mm/kasan/report.c:138
       [<ffffffff816fb0c5>] kasan_report_error+0x215/0x530 kernel/mm/kasan/report.c:236
       [<     inline     >] kasan_report kernel/mm/kasan/report.c:259
       [<ffffffff816fb4de>] __asan_report_load8_noabort+0x3e/0x40 kernel/mm/kasan/report.c:280
       [<     inline     >] ? ppp_pernet kernel/include/linux/compiler.h:218
       [<ffffffff83ad71b2>] ? ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
       [<     inline     >] ppp_pernet kernel/include/linux/compiler.h:218
       [<ffffffff83ad71b2>] ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
       [<     inline     >] ? ppp_pernet kernel/drivers/net/ppp/ppp_generic.c:293
       [<ffffffff83ad6f26>] ? ppp_unregister_channel+0xe6/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
       [<ffffffff83ae18f3>] ppp_asynctty_close+0xa3/0x130 kernel/drivers/net/ppp/ppp_async.c:241
       [<ffffffff83ae1850>] ? async_lcp_peek+0x5b0/0x5b0 kernel/drivers/net/ppp/ppp_async.c:1000
       [<ffffffff82c33239>] tty_ldisc_close.isra.1+0x99/0xe0 kernel/drivers/tty/tty_ldisc.c:478
       [<ffffffff82c332c0>] tty_ldisc_kill+0x40/0x170 kernel/drivers/tty/tty_ldisc.c:744
       [<ffffffff82c34943>] tty_ldisc_release+0x1b3/0x260 kernel/drivers/tty/tty_ldisc.c:772
       [<ffffffff82c1ef21>] tty_release+0xac1/0x13e0 kernel/drivers/tty/tty_io.c:1901
       [<ffffffff82c1e460>] ? release_tty+0x320/0x320 kernel/drivers/tty/tty_io.c:1688
       [<ffffffff8174de36>] __fput+0x236/0x780 kernel/fs/file_table.c:208
       [<ffffffff8174e405>] ____fput+0x15/0x20 kernel/fs/file_table.c:244
       [<ffffffff813595ab>] task_work_run+0x16b/0x200 kernel/kernel/task_work.c:115
       [<     inline     >] exit_task_work kernel/include/linux/task_work.h:21
       [<ffffffff81307105>] do_exit+0x8b5/0x2c60 kernel/kernel/exit.c:750
       [<ffffffff813fdd20>] ? debug_check_no_locks_freed+0x290/0x290 kernel/kernel/locking/lockdep.c:4123
       [<ffffffff81306850>] ? mm_update_next_owner+0x6f0/0x6f0 kernel/kernel/exit.c:357
       [<ffffffff813215e6>] ? __dequeue_signal+0x136/0x470 kernel/kernel/signal.c:550
       [<ffffffff8132067b>] ? recalc_sigpending_tsk+0x13b/0x180 kernel/kernel/signal.c:145
       [<ffffffff81309628>] do_group_exit+0x108/0x330 kernel/kernel/exit.c:880
       [<ffffffff8132b9d4>] get_signal+0x5e4/0x14f0 kernel/kernel/signal.c:2307
       [<     inline     >] ? kretprobe_table_lock kernel/kernel/kprobes.c:1113
       [<ffffffff8151d355>] ? kprobe_flush_task+0xb5/0x450 kernel/kernel/kprobes.c:1158
       [<ffffffff8115f7d3>] do_signal+0x83/0x1c90 kernel/arch/x86/kernel/signal.c:712
       [<ffffffff8151d2a0>] ? recycle_rp_inst+0x310/0x310 kernel/include/linux/list.h:655
       [<ffffffff8115f750>] ? setup_sigcontext+0x780/0x780 kernel/arch/x86/kernel/signal.c:165
       [<ffffffff81380864>] ? finish_task_switch+0x424/0x5f0 kernel/kernel/sched/core.c:2692
       [<     inline     >] ? finish_lock_switch kernel/kernel/sched/sched.h:1099
       [<ffffffff81380560>] ? finish_task_switch+0x120/0x5f0 kernel/kernel/sched/core.c:2678
       [<     inline     >] ? context_switch kernel/kernel/sched/core.c:2807
       [<ffffffff85d794e9>] ? __schedule+0x919/0x1bd0 kernel/kernel/sched/core.c:3283
       [<ffffffff81003901>] exit_to_usermode_loop+0xf1/0x1a0 kernel/arch/x86/entry/common.c:247
       [<     inline     >] prepare_exit_to_usermode kernel/arch/x86/entry/common.c:282
       [<ffffffff810062ef>] syscall_return_slowpath+0x19f/0x210 kernel/arch/x86/entry/common.c:344
       [<ffffffff85d88022>] int_ret_from_sys_call+0x25/0x9f kernel/arch/x86/entry/entry_64.S:281
      Memory state around the buggy address:
       ffff880064e21680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff880064e21700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      >ffff880064e21780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                             ^
       ffff880064e21800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff880064e21880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ==================================================================
      
      Fixes: 273ec51d ("net: ppp_generic - introduce net-namespace functionality v2")
      Reported-by: default avatarBaozeng Ding <sploving1@gmail.com>
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Reviewed-by: default avatarCyrill Gorcunov <gorcunov@openvz.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      c57d15c3
    • Manish Chopra's avatar
      qlge: Fix receive packets drop. · fb7d23cb
      Manish Chopra authored
      commit 2c9a266a upstream.
      
      When running small packets [length < 256 bytes] traffic, packets were
      being dropped due to invalid data in those packets which were
      delivered by the driver upto the stack. Using pci_dma_sync_single_for_cpu
      ensures copying latest and updated data into skb from the receive buffer.
      Signed-off-by: default avatarSony Chacko <sony.chacko@qlogic.com>
      Signed-off-by: default avatarManish Chopra <manish.chopra@qlogic.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      fb7d23cb
    • Arnd Bergmann's avatar
      ath9k: fix buffer overrun for ar9287 · d6a8ef9f
      Arnd Bergmann authored
      commit 83d6f1f1 upstream.
      
      Code that was added back in 2.6.38 has an obvious overflow
      when accessing a static array, and at the time it was added
      only a code comment was put in front of it as a reminder
      to have it reviewed properly.
      
      This has not happened, but gcc-6 now points to the specific
      overflow:
      
      drivers/net/wireless/ath/ath9k/eeprom.c: In function 'ath9k_hw_get_gain_boundaries_pdadcs':
      drivers/net/wireless/ath/ath9k/eeprom.c:483:44: error: array subscript is above array bounds [-Werror=array-bounds]
           maxPwrT4[i] = data_9287[idxL].pwrPdg[i][4];
                         ~~~~~~~~~~~~~~~~~~~~~~~~~^~~
      
      It turns out that the correct array length exists in the local
      'intercepts' variable of this function, so we can just use that
      instead of hardcoding '4', so this patch changes all three
      instances to use that variable. The other two instances were
      already correct, but it's more consistent this way.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: 940cd2c1 ("ath9k_hw: merge the ar9287 version of ath9k_hw_get_gain_boundaries_pdadcs")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      d6a8ef9f
    • Arnd Bergmann's avatar
      farsync: fix off-by-one bug in fst_add_one · 4d882b64
      Arnd Bergmann authored
      commit e725a66c upstream.
      
      gcc-6 finds an out of bounds access in the fst_add_one function
      when calculating the end of the mmio area:
      
      drivers/net/wan/farsync.c: In function 'fst_add_one':
      drivers/net/wan/farsync.c:418:53: error: index 2 denotes an offset greater than size of 'u8[2][8192] {aka unsigned char[2][8192]}' [-Werror=array-bounds]
       #define BUF_OFFSET(X)   (BFM_BASE + offsetof(struct buf_window, X))
                                                           ^
      include/linux/compiler-gcc.h:158:21: note: in definition of macro '__compiler_offsetof'
        __builtin_offsetof(a, b)
                           ^
      drivers/net/wan/farsync.c:418:37: note: in expansion of macro 'offsetof'
       #define BUF_OFFSET(X)   (BFM_BASE + offsetof(struct buf_window, X))
                                           ^~~~~~~~
      drivers/net/wan/farsync.c:2519:36: note: in expansion of macro 'BUF_OFFSET'
                                        + BUF_OFFSET ( txBuffer[i][NUM_TX_BUFFER][0]);
                                          ^~~~~~~~~~
      
      The warning is correct, but not critical because this appears
      to be a write-only variable that is set by each WAN driver but
      never accessed afterwards.
      
      I'm taking the minimal fix here, using the correct pointer by
      pointing 'mem_end' to the last byte inside of the register area
      as all other WAN drivers do, rather than the first byte outside of
      it. An alternative would be to just remove the mem_end member
      entirely.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      4d882b64
    • Arnaldo Carvalho de Melo's avatar
      net: Fix use after free in the recvmmsg exit path · 8ba9ba1a
      Arnaldo Carvalho de Melo authored
      commit 34b88a68 upstream.
      
      The syzkaller fuzzer hit the following use-after-free:
      
        Call Trace:
         [<ffffffff8175ea0e>] __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:295
         [<ffffffff851cc31a>] __sys_recvmmsg+0x6fa/0x7f0 net/socket.c:2261
         [<     inline     >] SYSC_recvmmsg net/socket.c:2281
         [<ffffffff851cc57f>] SyS_recvmmsg+0x16f/0x180 net/socket.c:2270
         [<ffffffff86332bb6>] entry_SYSCALL_64_fastpath+0x16/0x7a
        arch/x86/entry/entry_64.S:185
      
      And, as Dmitry rightly assessed, that is because we can drop the
      reference and then touch it when the underlying recvmsg calls return
      some packets and then hit an error, which will make recvmmsg to set
      sock->sk->sk_err, oops, fix it.
      Reported-and-Tested-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Kostya Serebryany <kcc@google.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Fixes: a2e27255 ("net: Introduce recvmmsg socket syscall")
      http://lkml.kernel.org/r/20160122211644.GC2470@redhat.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      8ba9ba1a
    • Sergei Shtylyov's avatar
      sh_eth: fix NULL pointer dereference in sh_eth_ring_format() · 0babba1b
      Sergei Shtylyov authored
      commit c1b7fca6 upstream.
      
      In a low memory situation, if netdev_alloc_skb() fails on a first RX ring
      loop iteration  in sh_eth_ring_format(), 'rxdesc' is still NULL.  Avoid
      kernel oops by adding the 'rxdesc' check after the loop.
      Reported-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      0babba1b