1. 17 Dec, 2018 30 commits
    • Hans de Goede's avatar
      iio/hid-sensors: Fix IIO_CHAN_INFO_RAW returning wrong values for signed numbers · aa17c9c0
      Hans de Goede authored
      [ Upstream commit 0145b505 ]
      
      Before this commit sensor_hub_input_attr_get_raw_value() failed to take
      the signedness of 16 and 8 bit values into account, returning e.g.
      65436 instead of -100 for the z-axis reading of an accelerometer.
      
      This commit adds a new is_signed parameter to the function and makes all
      callers pass the appropriate value for this.
      
      While at it, this commit also fixes up some neighboring lines where
      statements were needlessly split over 2 lines to improve readability.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Acked-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Acked-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      aa17c9c0
    • Tzung-Bi Shih's avatar
      ASoC: dapm: Recalculate audio map forcely when card instantiated · 55b648d1
      Tzung-Bi Shih authored
      [ Upstream commit 882eab6c ]
      
      Audio map are possible in wrong state before card->instantiated has
      been set to true.  Imaging the following examples:
      
      time 1: at the beginning
      
        in:-1    in:-1    in:-1    in:-1
       out:-1   out:-1   out:-1   out:-1
       SIGGEN        A        B      Spk
      
      time 2: after someone called snd_soc_dapm_new_widgets()
      (e.g. create_fill_widget_route_map() in sound/soc/codecs/hdac_hdmi.c)
      
         in:1     in:0     in:0     in:0
        out:0    out:0    out:0    out:1
       SIGGEN        A        B      Spk
      
      time 3: routes added
      
         in:1     in:0     in:0     in:0
        out:0    out:0    out:0    out:1
       SIGGEN -----> A -----> B ---> Spk
      
      In the end, the path should be powered on but it did not.  At time 3,
      "in" of SIGGEN and "out" of Spk did not propagate to their neighbors
      because snd_soc_dapm_add_path() will not invalidate the paths if
      the card has not instantiated (i.e. card->instantiated is false).
      To correct the state of audio map, recalculate the whole map forcely.
      Signed-off-by: default avatarTzung-Bi Shih <tzungbi@google.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      55b648d1
    • Peter Ujfalusi's avatar
      ASoC: omap-abe-twl6040: Fix missing audio card caused by deferred probing · b65b4228
      Peter Ujfalusi authored
      [ Upstream commit 76836fd3 ]
      
      The machine driver fails to probe in next-20181113 with:
      
      [    2.539093] omap-abe-twl6040 sound: ASoC: CODEC DAI twl6040-legacy not registered
      [    2.546630] omap-abe-twl6040 sound: devm_snd_soc_register_card() failed: -517
      ...
      [    3.693206] omap-abe-twl6040 sound: ASoC: Both platform name/of_node are set for TWL6040
      [    3.701446] omap-abe-twl6040 sound: ASoC: failed to init link TWL6040
      [    3.708007] omap-abe-twl6040 sound: devm_snd_soc_register_card() failed: -22
      [    3.715148] omap-abe-twl6040: probe of sound failed with error -22
      
      Bisect pointed to a merge commit:
      first bad commit: [0f688ab20a540aafa984c5dbd68a71debebf4d7f] Merge remote-tracking branch 'net-next/master'
      
      and a diff between a working kernel does not reveal anything which would
      explain the change in behavior.
      
      Further investigation showed that on the second try of loading fails
      because the dai_link->platform is no longer NULL and it might be pointing
      to uninitialized memory.
      
      The fix is to move the snd_soc_dai_link and snd_soc_card inside of the
      abe_twl6040 struct, which is dynamically allocated every time the driver
      probes.
      Signed-off-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b65b4228
    • Nicolin Chen's avatar
      hwmon: (ina2xx) Fix current value calculation · fd2c1ba1
      Nicolin Chen authored
      [ Upstream commit 38cd989e ]
      
      The current register (04h) has a sign bit at MSB. The comments
      for this calculation also mention that it's a signed register.
      
      However, the regval is unsigned type so result of calculation
      turns out to be an incorrect value when current is negative.
      
      This patch simply fixes this by adding a casting to s16.
      
      Fixes: 5d389b12 ("hwmon: (ina2xx) Make calibration register value fixed")
      Signed-off-by: default avatarNicolin Chen <nicoleotsuka@gmail.com>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      fd2c1ba1
    • Thomas Richter's avatar
      s390/cpum_cf: Reject request for sampling in event initialization · 250dea0d
      Thomas Richter authored
      [ Upstream commit 613a41b0 ]
      
      On s390 command perf top fails
      [root@s35lp76 perf] # ./perf top -F100000  --stdio
         Error:
         cycles: PMU Hardware doesn't support sampling/overflow-interrupts.
         	Try 'perf stat'
      [root@s35lp76 perf] #
      
      Using event -e rb0000 works as designed.  Event rb0000 is the event
      number of the sampling facility for basic sampling.
      
      During system start up the following PMUs are installed in the kernel's
      PMU list (from head to tail):
         cpum_cf --> s390 PMU counter facility device driver
         cpum_sf --> s390 PMU sampling facility device driver
         uprobe
         kprobe
         tracepoint
         task_clock
         cpu_clock
      
      Perf top executes following functions and calls perf_event_open(2) system
      call with different parameters many times:
      
      cmd_top
      --> __cmd_top
          --> perf_evlist__add_default
              --> __perf_evlist__add_default
                  --> perf_evlist__new_cycles (creates event type:0 (HW)
      			    		config 0 (CPU_CYCLES)
      	        --> perf_event_attr__set_max_precise_ip
      		    Uses perf_event_open(2) to detect correct
      		    precise_ip level. Fails 3 times on s390 which is ok.
      
      Then functions cmd_top
      --> __cmd_top
          --> perf_top__start_counters
              -->perf_evlist__config
      	   --> perf_can_comm_exec
                     --> perf_probe_api
      	           This functions test support for the following events:
      		   "cycles:u", "instructions:u", "cpu-clock:u" using
      		   --> perf_do_probe_api
      		       --> perf_event_open_cloexec
      		           Test the close on exec flag support with
      			   perf_event_open(2).
      	               perf_do_probe_api returns true if the event is
      		       supported.
      		       The function returns true because event cpu-clock is
      		       supported by the PMU cpu_clock.
      	               This is achieved by many calls to perf_event_open(2).
      
      Function perf_top__start_counters now calls perf_evsel__open() for every
      event, which is the default event cpu_cycles (config:0) and type HARDWARE
      (type:0) which a predfined frequence of 4000.
      
      Given the above order of the PMU list, the PMU cpum_cf gets called first
      and returns 0, which indicates support for this sampling. The event is
      fully allocated in the function perf_event_open (file kernel/event/core.c
      near line 10521 and the following check fails:
      
              event = perf_event_alloc(&attr, cpu, task, group_leader, NULL,
      		                 NULL, NULL, cgroup_fd);
      	if (IS_ERR(event)) {
      		err = PTR_ERR(event);
      		goto err_cred;
      	}
      
              if (is_sampling_event(event)) {
      		if (event->pmu->capabilities & PERF_PMU_CAP_NO_INTERRUPT) {
      			err = -EOPNOTSUPP;
      			goto err_alloc;
      		}
      	}
      
      The check for the interrupt capabilities fails and the system call
      perf_event_open() returns -EOPNOTSUPP (-95).
      
      Add a check to return -ENODEV when sampling is requested in PMU cpum_cf.
      This allows common kernel code in the perf_event_open() system call to
      test the next PMU in above list.
      
      Fixes: 97b1198f (" "s390, perf: Use common PMU interrupt disabled code")
      Signed-off-by: default avatarThomas Richter <tmricht@linux.ibm.com>
      Reviewed-by: default avatarHendrik Brueckner <brueckner@linux.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      250dea0d
    • Richard Fitzgerald's avatar
      ASoC: wm_adsp: Fix dma-unsafe read of scratch registers · 5391e32b
      Richard Fitzgerald authored
      [ Upstream commit 20e00db2 ]
      
      Stack memory isn't DMA-safe so it isn't safe to use either
      regmap_raw_read or regmap_bulk_read to read into stack memory.
      
      The two functions to read the scratch registers were using
      stack memory and regmap_raw_read. It's not worth allocating
      memory just for this trivial read, and it isn't time-critical.
      A simple regmap_read for each register is sufficient.
      Signed-off-by: default avatarRichard Fitzgerald <rf@opensource.cirrus.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5391e32b
    • Nicolin Chen's avatar
      hwmon (ina2xx) Fix NULL id pointer in probe() · de2324a0
      Nicolin Chen authored
      [ Upstream commit 70df9ebb ]
      
      When using DT configurations, the id pointer might turn out to
      be NULL. Then the driver encounters NULL pointer access:
      
        Unable to handle kernel read from unreadable memory at vaddr 00000018
        [...]
        PC is at ina2xx_probe+0x114/0x200
        LR is at ina2xx_probe+0x10c/0x200
        [...]
        Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
      
      The reason is that i2c core returns the id pointer by matching
      id_table with client->name, while the client->name is actually
      using the name from the first string in the DT compatible list,
      not the best one. So i2c core would fail to match the id_table
      if the best matched compatible string isn't the first one, and
      then would return a NULL id pointer.
      
      This probably should be fixed in i2c core. But it doesn't hurt
      to make the driver robust. So this patch fixes it by using the
      "chip" that's added to unify both DT and non-DT configurations.
      
      Additionally, since id pointer could be null, so as id->name:
        ina2xx 10-0047: power monitor (null) (Rshunt = 1000 uOhm)
        ina2xx 10-0048: power monitor (null) (Rshunt = 10000 uOhm)
      
      So this patch also fixes NULL name pointer, using client->name
      to play safe and to align with hwmon->name.
      
      Fixes: bd0ddd4d ("hwmon: (ina2xx) Add OF device ID table")
      Signed-off-by: default avatarNicolin Chen <nicoleotsuka@gmail.com>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      de2324a0
    • Florian Westphal's avatar
      netfilter: nf_tables: fix use-after-free when deleting compat expressions · 38e22947
      Florian Westphal authored
      [ Upstream commit 29e38801 ]
      
      nft_compat ops do not have static storage duration, unlike all other
      expressions.
      
      When nf_tables_expr_destroy() returns, expr->ops might have been
      free'd already, so we need to store next address before calling
      expression destructor.
      
      For same reason, we can't deref match pointer after nft_xt_put().
      
      This can be easily reproduced by adding msleep() before
      nft_match_destroy() returns.
      
      Fixes: 0ca743a5 ("netfilter: nf_tables: add compatibility layer for x_tables")
      Reported-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      38e22947
    • Florian Westphal's avatar
      selftests: add script to stress-test nft packet path vs. control plane · cae5446b
      Florian Westphal authored
      [ Upstream commit 25d8bced ]
      
      Start flood ping for each cpu while loading/flushing rulesets to make
      sure we do not access already-free'd rules from nf_tables evaluation loop.
      
      Also add this to TARGETS so 'make run_tests' in selftest dir runs it
      automatically.
      
      This would have caught the bug fixed in previous change
      ("netfilter: nf_tables: do not skip inactive chains during generation update")
      sooner.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cae5446b
    • YueHaibing's avatar
      sysv: return 'err' instead of 0 in __sysv_write_inode · 2ac368e8
      YueHaibing authored
      [ Upstream commit c4b7d1ba ]
      
      Fixes gcc '-Wunused-but-set-variable' warning:
      
      fs/sysv/inode.c: In function '__sysv_write_inode':
      fs/sysv/inode.c:239:6: warning:
       variable 'err' set but not used [-Wunused-but-set-variable]
      
      __sysv_write_inode should return 'err' instead of 0
      
      Fixes: 05459ca8 ("repair sysv_write_inode(), switch sysv to simple_fsync()")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2ac368e8
    • Janusz Krzysztofik's avatar
      ARM: OMAP1: ams-delta: Fix possible use of uninitialized field · 21ffeda1
      Janusz Krzysztofik authored
      [ Upstream commit cec83ff1 ]
      
      While playing with initialization order of modem device, it has been
      discovered that under some circumstances (early console init, I
      believe) its .pm() callback may be called before the
      uart_port->private_data pointer is initialized from
      plat_serial8250_port->private_data, resulting in NULL pointer
      dereference.  Fix it by checking for uninitialized pointer before using
      it in modem_pm().
      
      Fixes: aabf3173 ("ARM: OMAP1: ams-delta: update the modem to use regulator API")
      Signed-off-by: default avatarJanusz Krzysztofik <jmkrzyszt@gmail.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      21ffeda1
    • Adam Ford's avatar
      ARM: dts: logicpd-somlv: Fix interrupt on mmc3_dat1 · 5b2afd62
      Adam Ford authored
      [ Upstream commit 3d8b804b ]
      
      The interrupt on mmc3_dat1 is wrong which prevents this from
      appearing in /proc/interrupts.
      
      Fixes: ab8dd3ae ("ARM: DTS: Add minimal Support for Logic PD
      DM3730 SOM-LV") #Kernel 4.9+
      Signed-off-by: default avatarAdam Ford <aford173@gmail.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5b2afd62
    • Christophe JAILLET's avatar
      staging: rtl8723bs: Fix the return value in case of error in 'rtw_wx_read32()' · f55ad8d2
      Christophe JAILLET authored
      [ Upstream commit c3e43d8b ]
      
      We return 0 unconditionally in 'rtw_wx_read32()'.
      However, 'ret' is set to some error codes in several error handling paths.
      
      Return 'ret' instead to propagate the error code.
      
      Fixes: 554c0a3a ("staging: Add rtl8723bs sdio wifi driver")
      Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f55ad8d2
    • Kuninori Morimoto's avatar
      ASoC: rsnd: fixup clock start checker · b34888a9
      Kuninori Morimoto authored
      [ Upstream commit 3ee9a76a ]
      
      commit 4d230d12 ("ASoC: rsnd: fixup not to call clk_get/set under
      non-atomic") fixuped clock start timing. But it exchanged clock start
      checker from ssi->usrcnt to ssi->rate.
      
      Current rsnd_ssi_master_clk_start() is called from .prepare,
      but some player (for example GStreamer) might calls it many times.
      In such case, the checker might returns error even though it was not
      error. It should check ssi->usrcnt instead of ssi->rate.
      This patch fixup it. Without this patch, GStreamer can't switch
      48kHz / 44.1kHz.
      Reported-by: default avatarYusuke Goda <yusuke.goda.sx@renesas.com>
      Signed-off-by: default avatarKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Tested-by: default avatarYusuke Goda <yusuke.goda.sx@renesas.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b34888a9
    • Nathan Chancellor's avatar
      ARM: OMAP2+: prm44xx: Fix section annotation on omap44xx_prm_enable_io_wakeup · 635e16fc
      Nathan Chancellor authored
      [ Upstream commit eef3dc34 ]
      
      When building the kernel with Clang, the following section mismatch
      warning appears:
      
      WARNING: vmlinux.o(.text+0x38b3c): Section mismatch in reference from
      the function omap44xx_prm_late_init() to the function
      .init.text:omap44xx_prm_enable_io_wakeup()
      The function omap44xx_prm_late_init() references
      the function __init omap44xx_prm_enable_io_wakeup().
      This is often because omap44xx_prm_late_init lacks a __init
      annotation or the annotation of omap44xx_prm_enable_io_wakeup is wrong.
      
      Remove the __init annotation from omap44xx_prm_enable_io_wakeup so there
      is no more mismatch.
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      635e16fc
    • Jason Wang's avatar
      virtio-net: keep vnet header zeroed after processing XDP · 520e8609
      Jason Wang authored
      [ Upstream commit 436c9453 ]
      
      We copy vnet header unconditionally in page_to_skb() this is wrong
      since XDP may modify the packet data. So let's keep a zeroed vnet
      header for not confusing the conversion between vnet header and skb
      metadata.
      
      In the future, we should able to detect whether or not the packet was
      modified and keep using the vnet header when packet was not touched.
      
      Fixes: f600b690 ("virtio_net: Add XDP support")
      Reported-by: default avatarPavel Popa <pashinho1990@gmail.com>
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      520e8609
    • Nicolas Dichtel's avatar
      tun: forbid iface creation with rtnl ops · 1d2cda4e
      Nicolas Dichtel authored
      [ Upstream commit 35b827b6 ]
      
      It's not supported right now (the goal of the initial patch was to support
      'ip link del' only).
      
      Before the patch:
      $ ip link add foo type tun
      [  239.632660] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
      [snip]
      [  239.636410] RIP: 0010:register_netdevice+0x8e/0x3a0
      
      This panic occurs because dev->netdev_ops is not set by tun_setup(). But to
      have something usable, it will require more than just setting
      netdev_ops.
      
      Fixes: f019a7a5 ("tun: Implement ip link del tunXXX")
      CC: Eric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1d2cda4e
    • Yuchung Cheng's avatar
      tcp: fix NULL ref in tail loss probe · 6293016f
      Yuchung Cheng authored
      [ Upstream commit b2b7af86 ]
      
      TCP loss probe timer may fire when the retranmission queue is empty but
      has a non-zero tp->packets_out counter. tcp_send_loss_probe will call
      tcp_rearm_rto which triggers NULL pointer reference by fetching the
      retranmission queue head in its sub-routines.
      
      Add a more detailed warning to help catch the root cause of the inflight
      accounting inconsistency.
      Reported-by: default avatarRafael Tinoco <rafael.tinoco@linaro.org>
      Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6293016f
    • Eric Dumazet's avatar
      tcp: Do not underestimate rwnd_limited · 5567e5fe
      Eric Dumazet authored
      [ Upstream commit 41727549 ]
      
      If available rwnd is too small, tcp_tso_should_defer()
      can decide it is worth waiting before splitting a TSO packet.
      
      This really means we are rwnd limited.
      
      Fixes: 5615f886 ("tcp: instrument how long TCP is limited by receive window")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarSoheil Hassas Yeganeh <soheil@google.com>
      Reviewed-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5567e5fe
    • Xin Long's avatar
      sctp: kfree_rcu asoc · 862b5ab9
      Xin Long authored
      [ Upstream commit fb6df5a6 ]
      
      In sctp_hash_transport/sctp_epaddr_lookup_transport, it dereferences
      a transport's asoc under rcu_read_lock while asoc is freed not after
      a grace period, which leads to a use-after-free panic.
      
      This patch fixes it by calling kfree_rcu to make asoc be freed after
      a grace period.
      
      Note that only the asoc's memory is delayed to free in the patch, it
      won't cause sk to linger longer.
      
      Thanks Neil and Marcelo to make this clear.
      
      Fixes: 7fda702f ("sctp: use new rhlist interface on sctp transport rhashtable")
      Fixes: cd2b7087 ("sctp: check duplicate node before inserting a new transport")
      Reported-by: syzbot+0b05d8aa7cb185107483@syzkaller.appspotmail.com
      Reported-by: syzbot+aad231d51b1923158444@syzkaller.appspotmail.com
      Suggested-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      862b5ab9
    • Eric Dumazet's avatar
      rtnetlink: ndo_dflt_fdb_dump() only work for ARPHRD_ETHER devices · 22fa15e6
      Eric Dumazet authored
      [ Upstream commit 68883893 ]
      
      kmsan was able to trigger a kernel-infoleak using a gre device [1]
      
      nlmsg_populate_fdb_fill() has a hard coded assumption
      that dev->addr_len is ETH_ALEN, as normally guaranteed
      for ARPHRD_ETHER devices.
      
      A similar issue was fixed recently in commit da715775
      ("rtnetlink: Disallow FDB configuration for non-Ethernet device")
      
      [1]
      BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:143 [inline]
      BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x4c0/0x2700 lib/iov_iter.c:576
      CPU: 0 PID: 6697 Comm: syz-executor310 Not tainted 4.20.0-rc3+ #95
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x32d/0x480 lib/dump_stack.c:113
       kmsan_report+0x12c/0x290 mm/kmsan/kmsan.c:683
       kmsan_internal_check_memory+0x32a/0xa50 mm/kmsan/kmsan.c:743
       kmsan_copy_to_user+0x78/0xd0 mm/kmsan/kmsan_hooks.c:634
       copyout lib/iov_iter.c:143 [inline]
       _copy_to_iter+0x4c0/0x2700 lib/iov_iter.c:576
       copy_to_iter include/linux/uio.h:143 [inline]
       skb_copy_datagram_iter+0x4e2/0x1070 net/core/datagram.c:431
       skb_copy_datagram_msg include/linux/skbuff.h:3316 [inline]
       netlink_recvmsg+0x6f9/0x19d0 net/netlink/af_netlink.c:1975
       sock_recvmsg_nosec net/socket.c:794 [inline]
       sock_recvmsg+0x1d1/0x230 net/socket.c:801
       ___sys_recvmsg+0x444/0xae0 net/socket.c:2278
       __sys_recvmsg net/socket.c:2327 [inline]
       __do_sys_recvmsg net/socket.c:2337 [inline]
       __se_sys_recvmsg+0x2fa/0x450 net/socket.c:2334
       __x64_sys_recvmsg+0x4a/0x70 net/socket.c:2334
       do_syscall_64+0xcf/0x110 arch/x86/entry/common.c:291
       entry_SYSCALL_64_after_hwframe+0x63/0xe7
      RIP: 0033:0x441119
      Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007fffc7f008a8 EFLAGS: 00000207 ORIG_RAX: 000000000000002f
      RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000441119
      RDX: 0000000000000040 RSI: 00000000200005c0 RDI: 0000000000000003
      RBP: 00000000006cc018 R08: 0000000000000100 R09: 0000000000000100
      R10: 0000000000000100 R11: 0000000000000207 R12: 0000000000402080
      R13: 0000000000402110 R14: 0000000000000000 R15: 0000000000000000
      
      Uninit was stored to memory at:
       kmsan_save_stack_with_flags mm/kmsan/kmsan.c:246 [inline]
       kmsan_save_stack mm/kmsan/kmsan.c:261 [inline]
       kmsan_internal_chain_origin+0x13d/0x240 mm/kmsan/kmsan.c:469
       kmsan_memcpy_memmove_metadata+0x1a9/0xf70 mm/kmsan/kmsan.c:344
       kmsan_memcpy_metadata+0xb/0x10 mm/kmsan/kmsan.c:362
       __msan_memcpy+0x61/0x70 mm/kmsan/kmsan_instr.c:162
       __nla_put lib/nlattr.c:744 [inline]
       nla_put+0x20a/0x2d0 lib/nlattr.c:802
       nlmsg_populate_fdb_fill+0x444/0x810 net/core/rtnetlink.c:3466
       nlmsg_populate_fdb net/core/rtnetlink.c:3775 [inline]
       ndo_dflt_fdb_dump+0x73a/0x960 net/core/rtnetlink.c:3807
       rtnl_fdb_dump+0x1318/0x1cb0 net/core/rtnetlink.c:3979
       netlink_dump+0xc79/0x1c90 net/netlink/af_netlink.c:2244
       __netlink_dump_start+0x10c4/0x11d0 net/netlink/af_netlink.c:2352
       netlink_dump_start include/linux/netlink.h:216 [inline]
       rtnetlink_rcv_msg+0x141b/0x1540 net/core/rtnetlink.c:4910
       netlink_rcv_skb+0x394/0x640 net/netlink/af_netlink.c:2477
       rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4965
       netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
       netlink_unicast+0x1699/0x1740 net/netlink/af_netlink.c:1336
       netlink_sendmsg+0x13c7/0x1440 net/netlink/af_netlink.c:1917
       sock_sendmsg_nosec net/socket.c:621 [inline]
       sock_sendmsg net/socket.c:631 [inline]
       ___sys_sendmsg+0xe3b/0x1240 net/socket.c:2116
       __sys_sendmsg net/socket.c:2154 [inline]
       __do_sys_sendmsg net/socket.c:2163 [inline]
       __se_sys_sendmsg+0x305/0x460 net/socket.c:2161
       __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2161
       do_syscall_64+0xcf/0x110 arch/x86/entry/common.c:291
       entry_SYSCALL_64_after_hwframe+0x63/0xe7
      
      Uninit was created at:
       kmsan_save_stack_with_flags mm/kmsan/kmsan.c:246 [inline]
       kmsan_internal_poison_shadow+0x6d/0x130 mm/kmsan/kmsan.c:170
       kmsan_kmalloc+0xa1/0x100 mm/kmsan/kmsan_hooks.c:186
       __kmalloc+0x14c/0x4d0 mm/slub.c:3825
       kmalloc include/linux/slab.h:551 [inline]
       __hw_addr_create_ex net/core/dev_addr_lists.c:34 [inline]
       __hw_addr_add_ex net/core/dev_addr_lists.c:80 [inline]
       __dev_mc_add+0x357/0x8a0 net/core/dev_addr_lists.c:670
       dev_mc_add+0x6d/0x80 net/core/dev_addr_lists.c:687
       ip_mc_filter_add net/ipv4/igmp.c:1128 [inline]
       igmp_group_added+0x4d4/0xb80 net/ipv4/igmp.c:1311
       __ip_mc_inc_group+0xea9/0xf70 net/ipv4/igmp.c:1444
       ip_mc_inc_group net/ipv4/igmp.c:1453 [inline]
       ip_mc_up+0x1c3/0x400 net/ipv4/igmp.c:1775
       inetdev_event+0x1d03/0x1d80 net/ipv4/devinet.c:1522
       notifier_call_chain kernel/notifier.c:93 [inline]
       __raw_notifier_call_chain kernel/notifier.c:394 [inline]
       raw_notifier_call_chain+0x13d/0x240 kernel/notifier.c:401
       __dev_notify_flags+0x3da/0x860 net/core/dev.c:1733
       dev_change_flags+0x1ac/0x230 net/core/dev.c:7569
       do_setlink+0x165f/0x5ea0 net/core/rtnetlink.c:2492
       rtnl_newlink+0x2ad7/0x35a0 net/core/rtnetlink.c:3111
       rtnetlink_rcv_msg+0x1148/0x1540 net/core/rtnetlink.c:4947
       netlink_rcv_skb+0x394/0x640 net/netlink/af_netlink.c:2477
       rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4965
       netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
       netlink_unicast+0x1699/0x1740 net/netlink/af_netlink.c:1336
       netlink_sendmsg+0x13c7/0x1440 net/netlink/af_netlink.c:1917
       sock_sendmsg_nosec net/socket.c:621 [inline]
       sock_sendmsg net/socket.c:631 [inline]
       ___sys_sendmsg+0xe3b/0x1240 net/socket.c:2116
       __sys_sendmsg net/socket.c:2154 [inline]
       __do_sys_sendmsg net/socket.c:2163 [inline]
       __se_sys_sendmsg+0x305/0x460 net/socket.c:2161
       __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2161
       do_syscall_64+0xcf/0x110 arch/x86/entry/common.c:291
       entry_SYSCALL_64_after_hwframe+0x63/0xe7
      
      Bytes 36-37 of 105 are uninitialized
      Memory access of size 105 starts at ffff88819686c000
      Data copied to user address 0000000020000380
      
      Fixes: d83b0603 ("net: add fdb generic dump routine")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: John Fastabend <john.fastabend@gmail.com>
      Cc: Ido Schimmel <idosch@mellanox.com>
      Cc: David Ahern <dsahern@gmail.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      22fa15e6
    • Christoph Paasch's avatar
      net: Prevent invalid access to skb->prev in __qdisc_drop_all · 56ed9f33
      Christoph Paasch authored
      [ Upstream commit 9410d386 ]
      
      __qdisc_drop_all() accesses skb->prev to get to the tail of the
      segment-list.
      
      With commit 68d2f84a ("net: gro: properly remove skb from list")
      the skb-list handling has been changed to set skb->next to NULL and set
      the list-poison on skb->prev.
      
      With that change, __qdisc_drop_all() will panic when it tries to
      dereference skb->prev.
      
      Since commit 992cba7e ("net: Add and use skb_list_del_init().")
      __list_del_entry is used, leaving skb->prev unchanged (thus,
      pointing to the list-head if it's the first skb of the list).
      This will make __qdisc_drop_all modify the next-pointer of the list-head
      and result in a panic later on:
      
      [   34.501053] general protection fault: 0000 [#1] SMP KASAN PTI
      [   34.501968] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.20.0-rc2.mptcp #108
      [   34.502887] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.5.1 01/01/2011
      [   34.504074] RIP: 0010:dev_gro_receive+0x343/0x1f90
      [   34.504751] Code: e0 48 c1 e8 03 42 80 3c 30 00 0f 85 4a 1c 00 00 4d 8b 24 24 4c 39 65 d0 0f 84 0a 04 00 00 49 8d 7c 24 38 48 89 f8 48 c1 e8 03 <42> 0f b6 04 30 84 c0 74 08 3c 04
      [   34.507060] RSP: 0018:ffff8883af507930 EFLAGS: 00010202
      [   34.507761] RAX: 0000000000000007 RBX: ffff8883970b2c80 RCX: 1ffff11072e165a6
      [   34.508640] RDX: 1ffff11075867008 RSI: ffff8883ac338040 RDI: 0000000000000038
      [   34.509493] RBP: ffff8883af5079d0 R08: ffff8883970b2d40 R09: 0000000000000062
      [   34.510346] R10: 0000000000000034 R11: 0000000000000000 R12: 0000000000000000
      [   34.511215] R13: 0000000000000000 R14: dffffc0000000000 R15: ffff8883ac338008
      [   34.512082] FS:  0000000000000000(0000) GS:ffff8883af500000(0000) knlGS:0000000000000000
      [   34.513036] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   34.513741] CR2: 000055ccc3e9d020 CR3: 00000003abf32000 CR4: 00000000000006e0
      [   34.514593] Call Trace:
      [   34.514893]  <IRQ>
      [   34.515157]  napi_gro_receive+0x93/0x150
      [   34.515632]  receive_buf+0x893/0x3700
      [   34.516094]  ? __netif_receive_skb+0x1f/0x1a0
      [   34.516629]  ? virtnet_probe+0x1b40/0x1b40
      [   34.517153]  ? __stable_node_chain+0x4d0/0x850
      [   34.517684]  ? kfree+0x9a/0x180
      [   34.518067]  ? __kasan_slab_free+0x171/0x190
      [   34.518582]  ? detach_buf+0x1df/0x650
      [   34.519061]  ? lapic_next_event+0x5a/0x90
      [   34.519539]  ? virtqueue_get_buf_ctx+0x280/0x7f0
      [   34.520093]  virtnet_poll+0x2df/0xd60
      [   34.520533]  ? receive_buf+0x3700/0x3700
      [   34.521027]  ? qdisc_watchdog_schedule_ns+0xd5/0x140
      [   34.521631]  ? htb_dequeue+0x1817/0x25f0
      [   34.522107]  ? sch_direct_xmit+0x142/0xf30
      [   34.522595]  ? virtqueue_napi_schedule+0x26/0x30
      [   34.523155]  net_rx_action+0x2f6/0xc50
      [   34.523601]  ? napi_complete_done+0x2f0/0x2f0
      [   34.524126]  ? kasan_check_read+0x11/0x20
      [   34.524608]  ? _raw_spin_lock+0x7d/0xd0
      [   34.525070]  ? _raw_spin_lock_bh+0xd0/0xd0
      [   34.525563]  ? kvm_guest_apic_eoi_write+0x6b/0x80
      [   34.526130]  ? apic_ack_irq+0x9e/0xe0
      [   34.526567]  __do_softirq+0x188/0x4b5
      [   34.527015]  irq_exit+0x151/0x180
      [   34.527417]  do_IRQ+0xdb/0x150
      [   34.527783]  common_interrupt+0xf/0xf
      [   34.528223]  </IRQ>
      
      This patch makes sure that skb->prev is set to NULL when entering
      netem_enqueue.
      
      Cc: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
      Cc: Tyler Hicks <tyhicks@canonical.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Fixes: 68d2f84a ("net: gro: properly remove skb from list")
      Suggested-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarChristoph Paasch <cpaasch@apple.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      56ed9f33
    • Heiner Kallweit's avatar
      net: phy: don't allow __set_phy_supported to add unsupported modes · e44c8cbd
      Heiner Kallweit authored
      [ Upstream commit d2a36971 ]
      
      Currently __set_phy_supported allows to add modes w/o checking whether
      the PHY supports them. This is wrong, it should never add modes but
      only remove modes we don't want to support.
      
      The commit marked as fixed didn't do anything wrong, it just copied
      existing functionality to the helper which is being fixed now.
      
      Fixes: f3a6bd39 ("phylib: Add phy_set_max_speed helper")
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e44c8cbd
    • Eran Ben Elisha's avatar
      net/mlx4_en: Change min MTU size to ETH_MIN_MTU · 583e170c
      Eran Ben Elisha authored
      [ Upstream commit 24be19e4 ]
      
      NIC driver minimal MTU size shall be set to ETH_MIN_MTU, as defined in
      the RFC791 and in the network stack. Remove old mlx4_en only define for
      it, which was set to wrong value.
      
      Fixes: b80f71f5 ("ethernet/mellanox: use core min/max MTU checking")
      Signed-off-by: default avatarEran Ben Elisha <eranbe@mellanox.com>
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      583e170c
    • Tarick Bedeir's avatar
      net/mlx4_core: Correctly set PFC param if global pause is turned off. · 76f67ede
      Tarick Bedeir authored
      [ Upstream commit bd5122cd ]
      
      rx_ppp and tx_ppp can be set between 0 and 255, so don't clamp to 1.
      
      Fixes: 6e8814ce ("net/mlx4_en: Fix mixed PFC and Global pause user control requests")
      Signed-off-by: default avatarTarick Bedeir <tarick@google.com>
      Reviewed-by: default avatarEran Ben Elisha <eranbe@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      76f67ede
    • Su Yanjun's avatar
      net: 8139cp: fix a BUG triggered by changing mtu with network traffic · 4c65c73c
      Su Yanjun authored
      [ Upstream commit a5d4a892 ]
      
      When changing mtu many times with traffic, a bug is triggered:
      
      [ 1035.684037] kernel BUG at lib/dynamic_queue_limits.c:26!
      [ 1035.684042] invalid opcode: 0000 [#1] SMP
      [ 1035.684049] Modules linked in: loop binfmt_misc 8139cp(OE) macsec
      tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag tcp_lp
      fuse uinput xt_CHECKSUM iptable_mangle ipt_MASQUERADE
      nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4
      nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 tun
      bridge stp llc ebtable_filter ebtables ip6table_filter devlink
      ip6_tables iptable_filter sunrpc snd_hda_codec_generic snd_hda_intel
      snd_hda_codec snd_hda_core snd_hwdep ppdev snd_seq iosf_mbi crc32_pclmul
      parport_pc snd_seq_device ghash_clmulni_intel parport snd_pcm
      aesni_intel joydev lrw snd_timer virtio_balloon sg gf128mul glue_helper
      ablk_helper cryptd snd soundcore i2c_piix4 pcspkr ip_tables xfs
      libcrc32c sr_mod sd_mod cdrom crc_t10dif crct10dif_generic ata_generic
      [ 1035.684102]  pata_acpi virtio_console qxl drm_kms_helper syscopyarea
      sysfillrect sysimgblt floppy fb_sys_fops crct10dif_pclmul
      crct10dif_common ttm crc32c_intel serio_raw ata_piix drm libata 8139too
      virtio_pci drm_panel_orientation_quirks virtio_ring virtio mii dm_mirror
      dm_region_hash dm_log dm_mod [last unloaded: 8139cp]
      [ 1035.684132] CPU: 9 PID: 25140 Comm: if-mtu-change Kdump: loaded
      Tainted: G           OE  ------------ T 3.10.0-957.el7.x86_64 #1
      [ 1035.684134] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
      [ 1035.684136] task: ffff8f59b1f5a080 ti: ffff8f5a2e32c000 task.ti:
      ffff8f5a2e32c000
      [ 1035.684149] RIP: 0010:[<ffffffffba3a40d0>]  [<ffffffffba3a40d0>]
      dql_completed+0x180/0x190
      [ 1035.684162] RSP: 0000:ffff8f5a75483e50  EFLAGS: 00010093
      [ 1035.684162] RAX: 00000000000000c2 RBX: ffff8f5a6f91c000 RCX:
      0000000000000000
      [ 1035.684162] RDX: 0000000000000000 RSI: 0000000000000184 RDI:
      ffff8f599fea3ec0
      [ 1035.684162] RBP: ffff8f5a75483ea8 R08: 00000000000000c2 R09:
      0000000000000000
      [ 1035.684162] R10: 00000000000616ef R11: ffff8f5a75483b56 R12:
      ffff8f599fea3e00
      [ 1035.684162] R13: 0000000000000001 R14: 0000000000000000 R15:
      0000000000000184
      [ 1035.684162] FS:  00007fa8434de740(0000) GS:ffff8f5a75480000(0000)
      knlGS:0000000000000000
      [ 1035.684162] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 1035.684162] CR2: 00000000004305d0 CR3: 000000024eb66000 CR4:
      00000000001406e0
      [ 1035.684162] Call Trace:
      [ 1035.684162]  <IRQ>
      [ 1035.684162]  [<ffffffffc08cbaf8>] ? cp_interrupt+0x478/0x580 [8139cp]
      [ 1035.684162]  [<ffffffffba14a294>]
      __handle_irq_event_percpu+0x44/0x1c0
      [ 1035.684162]  [<ffffffffba14a442>] handle_irq_event_percpu+0x32/0x80
      [ 1035.684162]  [<ffffffffba14a4cc>] handle_irq_event+0x3c/0x60
      [ 1035.684162]  [<ffffffffba14db29>] handle_fasteoi_irq+0x59/0x110
      [ 1035.684162]  [<ffffffffba02e554>] handle_irq+0xe4/0x1a0
      [ 1035.684162]  [<ffffffffba7795dd>] do_IRQ+0x4d/0xf0
      [ 1035.684162]  [<ffffffffba76b362>] common_interrupt+0x162/0x162
      [ 1035.684162]  <EOI>
      [ 1035.684162]  [<ffffffffba0c2ae4>] ? __wake_up_bit+0x24/0x70
      [ 1035.684162]  [<ffffffffba1e46f5>] ? do_set_pte+0xd5/0x120
      [ 1035.684162]  [<ffffffffba1b64fb>] unlock_page+0x2b/0x30
      [ 1035.684162]  [<ffffffffba1e4879>] do_read_fault.isra.61+0x139/0x1b0
      [ 1035.684162]  [<ffffffffba1e9134>] handle_pte_fault+0x2f4/0xd10
      [ 1035.684162]  [<ffffffffba1ebc6d>] handle_mm_fault+0x39d/0x9b0
      [ 1035.684162]  [<ffffffffba76f5e3>] __do_page_fault+0x203/0x500
      [ 1035.684162]  [<ffffffffba76f9c6>] trace_do_page_fault+0x56/0x150
      [ 1035.684162]  [<ffffffffba76ef42>] do_async_page_fault+0x22/0xf0
      [ 1035.684162]  [<ffffffffba76b788>] async_page_fault+0x28/0x30
      [ 1035.684162] Code: 54 c7 47 54 ff ff ff ff 44 0f 49 ce 48 8b 35 48 2f
      9c 00 48 89 77 58 e9 fe fe ff ff 0f 1f 80 00 00 00 00 41 89 d1 e9 ef fe
      ff ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 55 8d 42 ff 48
      [ 1035.684162] RIP  [<ffffffffba3a40d0>] dql_completed+0x180/0x190
      [ 1035.684162]  RSP <ffff8f5a75483e50>
      
      It's not the same as in 7fe0ee09 patch described.
      As 8139cp uses shared irq mode, other device irq will trigger
      cp_interrupt to execute.
      
      cp_change_mtu
       -> cp_close
       -> cp_open
      
      In cp_close routine  just before free_irq(), some interrupt may occur.
      In my environment, cp_interrupt exectutes and IntrStatus is 0x4,
      exactly TxOk. That will cause cp_tx to wake device queue.
      
      As device queue is started, cp_start_xmit and cp_open will run at same
      time which will cause kernel BUG.
      
      For example:
      [#] for tx descriptor
      
      At start:
      
      [#][#][#]
      num_queued=3
      
      After cp_init_hw->cp_start_hw->netdev_reset_queue:
      
      [#][#][#]
      num_queued=0
      
      When 8139cp starts to work then cp_tx will check
      num_queued mismatchs the complete_bytes.
      
      The patch will check IntrMask before check IntrStatus in cp_interrupt.
      When 8139cp interrupt is disabled, just return.
      Signed-off-by: default avatarSu Yanjun <suyj.fnst@cn.fujitsu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4c65c73c
    • Shmulik Ladkani's avatar
      ipv6: sr: properly initialize flowi6 prior passing to ip6_route_output · 25f111f2
      Shmulik Ladkani authored
      [ Upstream commit 1b4e5ad5 ]
      
      In 'seg6_output', stack variable 'struct flowi6 fl6' was missing
      initialization.
      
      Fixes: 6c8702c6 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")
      Signed-off-by: default avatarShmulik Ladkani <shmulik.ladkani@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      25f111f2
    • Stefano Brivio's avatar
      neighbour: Avoid writing before skb->head in neigh_hh_output() · 9380dc7c
      Stefano Brivio authored
      [ Upstream commit e6ac64d4 ]
      
      While skb_push() makes the kernel panic if the skb headroom is less than
      the unaligned hardware header size, it will proceed normally in case we
      copy more than that because of alignment, and we'll silently corrupt
      adjacent slabs.
      
      In the case fixed by the previous patch,
      "ipv6: Check available headroom in ip6_xmit() even without options", we
      end up in neigh_hh_output() with 14 bytes headroom, 14 bytes hardware
      header and write 16 bytes, starting 2 bytes before the allocated buffer.
      
      Always check we're not writing before skb->head and, if the headroom is
      not enough, warn and drop the packet.
      
      v2:
       - instead of panicking with BUG_ON(), WARN_ON_ONCE() and drop the packet
         (Eric Dumazet)
       - if we avoid the panic, though, we need to explicitly check the headroom
         before the memcpy(), otherwise we'll have corrupted slabs on a running
         kernel, after we warn
       - use __skb_push() instead of skb_push(), as the headroom check is
         already implemented here explicitly (Eric Dumazet)
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9380dc7c
    • Stefano Brivio's avatar
      ipv6: Check available headroom in ip6_xmit() even without options · ece6a4b7
      Stefano Brivio authored
      [ Upstream commit 66033f47 ]
      
      Even if we send an IPv6 packet without options, MAX_HEADER might not be
      enough to account for the additional headroom required by alignment of
      hardware headers.
      
      On a configuration without HYPERV_NET, WLAN, AX25, and with IPV6_TUNNEL,
      sending short SCTP packets over IPv4 over L2TP over IPv6, we start with
      100 bytes of allocated headroom in sctp_packet_transmit(), end up with 54
      bytes after l2tp_xmit_skb(), and 14 bytes in ip6_finish_output2().
      
      Those would be enough to append our 14 bytes header, but we're going to
      align that to 16 bytes, and write 2 bytes out of the allocated slab in
      neigh_hh_output().
      
      KASan says:
      
      [  264.967848] ==================================================================
      [  264.967861] BUG: KASAN: slab-out-of-bounds in ip6_finish_output2+0x1aec/0x1c70
      [  264.967866] Write of size 16 at addr 000000006af1c7fe by task netperf/6201
      [  264.967870]
      [  264.967876] CPU: 0 PID: 6201 Comm: netperf Not tainted 4.20.0-rc4+ #1
      [  264.967881] Hardware name: IBM 2827 H43 400 (z/VM 6.4.0)
      [  264.967887] Call Trace:
      [  264.967896] ([<00000000001347d6>] show_stack+0x56/0xa0)
      [  264.967903]  [<00000000017e379c>] dump_stack+0x23c/0x290
      [  264.967912]  [<00000000007bc594>] print_address_description+0xf4/0x290
      [  264.967919]  [<00000000007bc8fc>] kasan_report+0x13c/0x240
      [  264.967927]  [<000000000162f5e4>] ip6_finish_output2+0x1aec/0x1c70
      [  264.967935]  [<000000000163f890>] ip6_finish_output+0x430/0x7f0
      [  264.967943]  [<000000000163fe44>] ip6_output+0x1f4/0x580
      [  264.967953]  [<000000000163882a>] ip6_xmit+0xfea/0x1ce8
      [  264.967963]  [<00000000017396e2>] inet6_csk_xmit+0x282/0x3f8
      [  264.968033]  [<000003ff805fb0ba>] l2tp_xmit_skb+0xe02/0x13e0 [l2tp_core]
      [  264.968037]  [<000003ff80631192>] l2tp_eth_dev_xmit+0xda/0x150 [l2tp_eth]
      [  264.968041]  [<0000000001220020>] dev_hard_start_xmit+0x268/0x928
      [  264.968069]  [<0000000001330e8e>] sch_direct_xmit+0x7ae/0x1350
      [  264.968071]  [<000000000122359c>] __dev_queue_xmit+0x2b7c/0x3478
      [  264.968075]  [<00000000013d2862>] ip_finish_output2+0xce2/0x11a0
      [  264.968078]  [<00000000013d9b14>] ip_finish_output+0x56c/0x8c8
      [  264.968081]  [<00000000013ddd1e>] ip_output+0x226/0x4c0
      [  264.968083]  [<00000000013dbd6c>] __ip_queue_xmit+0x894/0x1938
      [  264.968100]  [<000003ff80bc3a5c>] sctp_packet_transmit+0x29d4/0x3648 [sctp]
      [  264.968116]  [<000003ff80b7bf68>] sctp_outq_flush_ctrl.constprop.5+0x8d0/0xe50 [sctp]
      [  264.968131]  [<000003ff80b7c716>] sctp_outq_flush+0x22e/0x7d8 [sctp]
      [  264.968146]  [<000003ff80b35c68>] sctp_cmd_interpreter.isra.16+0x530/0x6800 [sctp]
      [  264.968161]  [<000003ff80b3410a>] sctp_do_sm+0x222/0x648 [sctp]
      [  264.968177]  [<000003ff80bbddac>] sctp_primitive_ASSOCIATE+0xbc/0xf8 [sctp]
      [  264.968192]  [<000003ff80b93328>] __sctp_connect+0x830/0xc20 [sctp]
      [  264.968208]  [<000003ff80bb11ce>] sctp_inet_connect+0x2e6/0x378 [sctp]
      [  264.968212]  [<0000000001197942>] __sys_connect+0x21a/0x450
      [  264.968215]  [<000000000119aff8>] sys_socketcall+0x3d0/0xb08
      [  264.968218]  [<000000000184ea7a>] system_call+0x2a2/0x2c0
      
      [...]
      
      Just like ip_finish_output2() does for IPv4, check that we have enough
      headroom in ip6_xmit(), and reallocate it if we don't.
      
      This issue is older than git history.
      Reported-by: default avatarJianlin Shi <jishi@redhat.com>
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ece6a4b7
    • Jiri Wiesner's avatar
      ipv4: ipv6: netfilter: Adjust the frag mem limit when truesize changes · da4b6929
      Jiri Wiesner authored
      [ Upstream commit ebaf39e6 ]
      
      The *_frag_reasm() functions are susceptible to miscalculating the byte
      count of packet fragments in case the truesize of a head buffer changes.
      The truesize member may be changed by the call to skb_unclone(), leaving
      the fragment memory limit counter unbalanced even if all fragments are
      processed. This miscalculation goes unnoticed as long as the network
      namespace which holds the counter is not destroyed.
      
      Should an attempt be made to destroy a network namespace that holds an
      unbalanced fragment memory limit counter the cleanup of the namespace
      never finishes. The thread handling the cleanup gets stuck in
      inet_frags_exit_net() waiting for the percpu counter to reach zero. The
      thread is usually in running state with a stacktrace similar to:
      
       PID: 1073   TASK: ffff880626711440  CPU: 1   COMMAND: "kworker/u48:4"
        #5 [ffff880621563d48] _raw_spin_lock at ffffffff815f5480
        #6 [ffff880621563d48] inet_evict_bucket at ffffffff8158020b
        #7 [ffff880621563d80] inet_frags_exit_net at ffffffff8158051c
        #8 [ffff880621563db0] ops_exit_list at ffffffff814f5856
        #9 [ffff880621563dd8] cleanup_net at ffffffff814f67c0
       #10 [ffff880621563e38] process_one_work at ffffffff81096f14
      
      It is not possible to create new network namespaces, and processes
      that call unshare() end up being stuck in uninterruptible sleep state
      waiting to acquire the net_mutex.
      
      The bug was observed in the IPv6 netfilter code by Per Sundstrom.
      I thank him for his analysis of the problem. The parts of this patch
      that apply to IPv4 and IPv6 fragment reassembly are preemptive measures.
      Signed-off-by: default avatarJiri Wiesner <jwiesner@suse.com>
      Reported-by: default avatarPer Sundstrom <per.sundstrom@redqube.se>
      Acked-by: default avatarPeter Oskolkov <posk@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      da4b6929
  2. 13 Dec, 2018 10 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.14.88 · 1bb538a3
      Greg Kroah-Hartman authored
      1bb538a3
    • Emmanuel Grumbach's avatar
      mac80211: ignore NullFunc frames in the duplicate detection · 7b6d9327
      Emmanuel Grumbach authored
      commit 990d7184 upstream.
      
      NullFunc packets should never be duplicate just like
      QoS-NullFunc packets.
      
      We saw a client that enters / exits power save with
      NullFunc frames (and not with QoS-NullFunc) despite the
      fact that the association supports HT.
      This specific client also re-uses a non-zero sequence number
      for different NullFunc frames.
      At some point, the client had to send a retransmission of
      the NullFunc frame and we dropped it, leading to a
      misalignment in the power save state.
      Fix this by never consider a NullFunc frame as duplicate,
      just like we do for QoS NullFunc frames.
      
      This fixes https://bugzilla.kernel.org/show_bug.cgi?id=201449
      
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7b6d9327
    • Felix Fietkau's avatar
      mac80211: fix reordering of buffered broadcast packets · bbc4242a
      Felix Fietkau authored
      commit 9ec1190d upstream.
      
      If the buffered broadcast queue contains packets, letting new packets bypass
      that queue can lead to heavy reordering, since the driver is probably throttling
      transmission of buffered multicast packets after beacons.
      
      Keep buffering packets until the buffer has been cleared (and no client
      is in powersave mode).
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bbc4242a
    • Felix Fietkau's avatar
      mac80211: ignore tx status for PS stations in ieee80211_tx_status_ext · a2c934fb
      Felix Fietkau authored
      commit a317e65f upstream.
      
      Make it behave like regular ieee80211_tx_status calls, except for the lack of
      filtered frame processing.
      This fixes spurious low-ack triggered disconnections with powersave clients
      connected to an AP.
      
      Fixes: f027c2ac ("mac80211: add ieee80211_tx_status_noskb")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a2c934fb
    • Ben Greear's avatar
      mac80211: Clear beacon_int in ieee80211_do_stop · 9e82abdd
      Ben Greear authored
      commit 5c21e810 upstream.
      
      This fixes stale beacon-int values that would keep a netdev
      from going up.
      
      To reproduce:
      
      Create two VAP on one radio.
      vap1 has beacon-int 100, start it.
      vap2 has beacon-int 240, start it (and it will fail
        because beacon-int mismatch).
      reconfigure vap2 to have beacon-int 100 and start it.
        It will fail because the stale beacon-int 240 will be used
        in the ifup path and hostapd never gets a chance to set the
        new beacon interval.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBen Greear <greearb@candelatech.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9e82abdd
    • Vasyl Vavrychuk's avatar
      mac80211_hwsim: Timer should be initialized before device registered · 199a81ac
      Vasyl Vavrychuk authored
      commit a1881c9b upstream.
      
      Otherwise if network manager starts configuring Wi-Fi interface
      immidiatelly after getting notification of its creation, we will get
      NULL pointer dereference:
      
        BUG: unable to handle kernel NULL pointer dereference at           (null)
        IP: [<ffffffff95ae94c8>] hrtimer_active+0x28/0x50
        ...
        Call Trace:
         [<ffffffff95ae9997>] ? hrtimer_try_to_cancel+0x27/0x110
         [<ffffffff95ae9a95>] ? hrtimer_cancel+0x15/0x20
         [<ffffffffc0803bf0>] ? mac80211_hwsim_config+0x140/0x1c0 [mac80211_hwsim]
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarVasyl Vavrychuk <vasyl.vavrychuk@globallogic.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      199a81ac
    • Dan Williams's avatar
      libnvdimm, pfn: Pad pfn namespaces relative to other regions · 4794d94b
      Dan Williams authored
      commit ae86cbfe upstream.
      
      Commit cfe30b87 "libnvdimm, pmem: adjust for section collisions with
      'System RAM'" enabled Linux to workaround occasions where platform
      firmware arranges for "System RAM" and "Persistent Memory" to collide
      within a single section boundary. Unfortunately, as reported in this
      issue [1], platform firmware can inflict the same collision between
      persistent memory regions.
      
      The approach of interrogating iomem_resource does not work in this
      case because platform firmware may merge multiple regions into a single
      iomem_resource range. Instead provide a method to interrogate regions
      that share the same parent bus.
      
      This is a stop-gap until the core-MM can grow support for hotplug on
      sub-section boundaries.
      
      [1]: https://github.com/pmem/ndctl/issues/76
      
      Fixes: cfe30b87 ("libnvdimm, pmem: adjust for section collisions with...")
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarPatrick Geary <patrickg@supermicro.com>
      Tested-by: default avatarPatrick Geary <patrickg@supermicro.com>
      Reviewed-by: default avatarVishal Verma <vishal.l.verma@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4794d94b
    • Macpaul Lin's avatar
      kgdboc: fix KASAN global-out-of-bounds bug in param_set_kgdboc_var() · b919b484
      Macpaul Lin authored
      commit dada6a43 upstream.
      
      This patch is trying to fix KE issue due to
      "BUG: KASAN: global-out-of-bounds in param_set_kgdboc_var+0x194/0x198"
      reported by Syzkaller scan."
      
      [26364:syz-executor0][name:report8t]BUG: KASAN: global-out-of-bounds in param_set_kgdboc_var+0x194/0x198
      [26364:syz-executor0][name:report&]Read of size 1 at addr ffffff900e44f95f by task syz-executor0/26364
      [26364:syz-executor0][name:report&]
      [26364:syz-executor0]CPU: 7 PID: 26364 Comm: syz-executor0 Tainted: G W 0
      [26364:syz-executor0]Call trace:
      [26364:syz-executor0][<ffffff9008095cf8>] dump_bacIctrace+Ox0/0x470
      [26364:syz-executor0][<ffffff9008096de0>] show_stack+0x20/0x30
      [26364:syz-executor0][<ffffff90089cc9c8>] dump_stack+Oxd8/0x128
      [26364:syz-executor0][<ffffff90084edb38>] print_address_description +0x80/0x4a8
      [26364:syz-executor0][<ffffff90084ee270>] kasan_report+Ox178/0x390
      [26364:syz-executor0][<ffffff90084ee4a0>] _asan_report_loadi_noabort+Ox18/0x20
      [26364:syz-executor0][<ffffff9008b092ac>] param_set_kgdboc_var+Ox194/0x198
      [26364:syz-executor0][<ffffff900813af64>] param_attr_store+Ox14c/0x270
      [26364:syz-executor0][<ffffff90081394c8>] module_attr_store+0x60/0x90
      [26364:syz-executor0][<ffffff90086690c0>] sysfs_kl_write+Ox100/0x158
      [26364:syz-executor0][<ffffff9008666d84>] kernfs_fop_write+0x27c/0x3a8
      [26364:syz-executor0][<ffffff9008508264>] do_loop_readv_writev+0x114/0x1b0
      [26364:syz-executor0][<ffffff9008509ac8>] do_readv_writev+0x4f8/0x5e0
      [26364:syz-executor0][<ffffff9008509ce4>] vfs_writev+0x7c/Oxb8
      [26364:syz-executor0][<ffffff900850ba64>] SyS_writev+Oxcc/0x208
      [26364:syz-executor0][<ffffff90080883f0>] elO_svc_naked +0x24/0x28
      [26364:syz-executor0][name:report&]
      [26364:syz-executor0][name:report&]The buggy address belongs to the variable:
      [26364:syz-executor0][name:report&] kgdb_tty_line+Ox3f/0x40
      [26364:syz-executor0][name:report&]
      [26364:syz-executor0][name:report&]Memory state around the buggy address:
      [26364:syz-executor0] ffffff900e44f800: 00 00 00 00 00 04 fa fa fa fa fa fa 00 fa fa fa
      [26364:syz-executor0] ffffff900e44f880: fa fa fa fa 00 fa fa fa fa fa fa fa 00 fa fa fa
      [26364:syz-executor0]> ffffff900e44f900: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00
      [26364:syz-executor0][name:report&]                                       ^
      [26364:syz-executor0] ffffff900e44f980: 00 fa fa fa fa fa fa fa 04 fa fa fa fa fa fa fa
      [26364:syz-executor0] ffffff900e44fa00: 04 fa fa fa fa fa fa fa 00 fa fa fa fa fa fa fa
      [26364:syz-executor0][name:report&]
      [26364:syz-executor0][name:panic&]Disabling lock debugging due to kernel taint
      [26364:syz-executor0]------------[cut here]------------
      
      After checking the source code, we've found there might be an out-of-bounds
      access to "config[len - 1]" array when the variable "len" is zero.
      Signed-off-by: default avatarMacpaul Lin <macpaul@gmail.com>
      Acked-by: default avatarDaniel Thompson <daniel.thompson@linaro.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b919b484
    • Chanho Park's avatar
      tty: do not set TTY_IO_ERROR flag if console port · e4c3cc6b
      Chanho Park authored
      commit 2a486026 upstream.
      
      Since Commit 761ed4a9 ('tty: serial_core: convert uart_close to use
      tty_port_close') and Commit 4dda864d ('tty: serial_core: Fix serial
      console crash on port shutdown), a serial port which is used as
      console can be stuck when logging out if there is a remained process.
      After logged out, agetty will try to grab the serial port but it will
      be failed because the previous process did not release the port
      correctly. To fix this, TTY_IO_ERROR bit should not be enabled of
      tty_port_close if the port is console port.
      
      Reproduce step:
      - Run background processes from serial console
      $ while true; do sleep 10; done &
      
      - Log out
      $ logout
      -> Stuck
      
      - Read journal log by journalctl | tail
      Jan 28 16:07:01 ubuntu systemd[1]: Stopped Serial Getty on ttyAMA0.
      Jan 28 16:07:01 ubuntu systemd[1]: Started Serial Getty on ttyAMA0.
      Jan 28 16:07:02 ubuntu agetty[1643]: /dev/ttyAMA0: not a tty
      
      Fixes: 761ed4a9 ("tty: serial_core: convert uart_close to use tty_port_close")
      Cc: Geert Uytterhoeven <geert+renesas@glider.be>
      Cc: Rob Herring <robh@kernel.org>
      Cc: Jiri Slaby <jslaby@suse.com>
      Signed-off-by: default avatarChanho Park <parkch98@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e4c3cc6b
    • Peter Shih's avatar
      tty: serial: 8250_mtk: always resume the device in probe. · 4f50d3a0
      Peter Shih authored
      commit 100bc3e2 upstream.
      
      serial8250_register_8250_port calls uart_config_port, which calls
      config_port on the port before it tries to power on the port. So we need
      the port to be on before calling serial8250_register_8250_port. Change
      the code to always do a runtime resume in probe before registering port,
      and always do a runtime suspend in remove.
      
      This basically reverts the change in commit 68e5fc4a ("tty: serial:
      8250_mtk: use pm_runtime callbacks for enabling"), but still use
      pm_runtime callbacks.
      
      Fixes: 68e5fc4a ("tty: serial: 8250_mtk: use pm_runtime callbacks for enabling")
      Signed-off-by: default avatarPeter Shih <pihsun@chromium.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4f50d3a0