1. 29 Jan, 2019 1 commit
    • Tony Lindgren's avatar
      bus: ti-sysc: Fix timer handling with drop pm_runtime_irq_safe() · 9bd34c63
      Tony Lindgren authored
      Commit 84badc5e ("ARM: dts: omap4: Move l4 child devices to probe
      them with ti-sysc") started producing a warning for pwm-omap-dmtimer:
      
      WARNING: CPU: 0 PID: 77 at drivers/bus/omap_l3_noc.c:147
      l3_interrupt_handler+0x2f8/0x388
      44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4PER2 (Idle):
      Data Access in Supervisor mode during Functional access
      ...
      __pm_runtime_idle
      omap_dm_timer_disable
      pwm_omap_dmtimer_start
      pwm_omap_dmtimer_enable
      pwm_apply_state
      pwm_vibrator_start
      pwm_vibrator_play_work
      
      This is because the timer that pwm-omap-dmtimer is using is now being
      probed with ti-sysc interconnect target module instead of omap_device
      and the ti-sysc quirk for SYSC_QUIRK_LEGACY_IDLE is not fully
      compatible with what omap_device has been doing.
      
      We could fix this by reverting the timer changes and have the timer
      probe again with omap_device. Or we could add more quirk handling to
      ti-sysc driver. But as these options don't work nicely as longer term
      solutions, let's just make timers probe with ti-sysc without any
      quirks.
      
      To do this, all we need to do is remove quirks for timers for ti-sysc,
      and drop the bogus pm_runtime_irq_safe() flag for timer-ti-dm.
      
      We should not use pm_runtime_irq_safe() anyways for drivers as it will
      take a permanent use count on the parent device blocking the parent
      devices from idling and has been forcing ti-sysc driver to use a
      quirk flag.
      
      Note that we will move the timer data to DEBUG section later on in
      clean-up patches.
      
      Fixes: 84badc5e ("ARM: dts: omap4: Move l4 child devices to probe them with ti-sysc")
      Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
      Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
      Cc: H. Nikolaus Schaller <hns@goldelico.com>
      Cc: Keerthy <j-keerthy@ti.com>
      Cc: Ladislav Michl <ladis@linux-mips.org>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Sebastian Reichel <sre@kernel.org>
      Cc: Tero Kristo <t-kristo@ti.com>
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Reported-by: default avatarH. Nikolaus Schaller <hns@goldelico.com>
      Tested-By: default avatarAndreas Kemnade <andreas@kemnade.info>
      Tested-By: default avatarH. Nikolaus Schaller <hns@goldelico.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      9bd34c63
  2. 22 Jan, 2019 1 commit
    • Tony Lindgren's avatar
      clocksource: timer-ti-dm: Fix pwm dmtimer usage of fck reparenting · 983a5a43
      Tony Lindgren authored
      Commit 84badc5e ("ARM: dts: omap4: Move l4 child devices to probe
      them with ti-sysc") moved some omap4 timers to probe with ti-sysc
      interconnect target module. Turns out this broke pwm-omap-dmtimer
      where we now try to reparent the clock to itself with the following:
      
      omap_dm_timer_of_set_source: failed to set parent
      
      With ti-sysc, we can now configure the clock sources in the dts
      with assigned-clocks and assigned-clock-parents. So we should be able
      to remove omap_dm_timer_of_set_source with clean-up patches later on.
      But for now, let's just fix it first by checking if parent and fck
      are the same and bail out of so.
      
      Fixes: 84badc5e ("ARM: dts: omap4: Move l4 child devices to probe them with ti-sysc")
      Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
      Cc: H. Nikolaus Schaller <hns@goldelico.com>
      Cc: Keerthy <j-keerthy@ti.com>
      Cc: Ladislav Michl <ladis@linux-mips.org>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Sebastian Reichel <sre@kernel.org>
      Cc: Tero Kristo <t-kristo@ti.com>
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Reported-by: default avatarH. Nikolaus Schaller <hns@goldelico.com>
      Tested-By: default avatarAndreas Kemnade <andreas@kemnade.info>
      Tested-By: default avatarH. Nikolaus Schaller <hns@goldelico.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      983a5a43
  3. 22 Oct, 2018 8 commits
  4. 21 Oct, 2018 3 commits
  5. 20 Oct, 2018 11 commits
  6. 19 Oct, 2018 13 commits
  7. 18 Oct, 2018 3 commits
    • Stefano Brivio's avatar
      ip6_tunnel: Fix encapsulation layout · d4d576f5
      Stefano Brivio authored
      Commit 058214a4 ("ip6_tun: Add infrastructure for doing
      encapsulation") added the ip6_tnl_encap() call in ip6_tnl_xmit(), before
      the call to ipv6_push_frag_opts() to append the IPv6 Tunnel Encapsulation
      Limit option (option 4, RFC 2473, par. 5.1) to the outer IPv6 header.
      
      As long as the option didn't actually end up in generated packets, this
      wasn't an issue. Then commit 89a23c8b ("ip6_tunnel: Fix missing tunnel
      encapsulation limit option") fixed sending of this option, and the
      resulting layout, e.g. for FoU, is:
      
      .-------------------.------------.----------.-------------------.----- - -
      | Outer IPv6 Header | UDP header | Option 4 | Inner IPv6 Header | Payload
      '-------------------'------------'----------'-------------------'----- - -
      
      Needless to say, FoU and GUE (at least) won't work over IPv6. The option
      is appended by default, and I couldn't find a way to disable it with the
      current iproute2.
      
      Turn this into a more reasonable:
      
      .-------------------.----------.------------.-------------------.----- - -
      | Outer IPv6 Header | Option 4 | UDP header | Inner IPv6 Header | Payload
      '-------------------'----------'------------'-------------------'----- - -
      
      With this, and with 84dad559 ("udp6: fix encap return code for
      resubmitting"), FoU and GUE work again over IPv6.
      
      Fixes: 058214a4 ("ip6_tun: Add infrastructure for doing encapsulation")
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d4d576f5
    • Jon Maloy's avatar
      tipc: fix info leak from kernel tipc_event · b06f9d9f
      Jon Maloy authored
      We initialize a struct tipc_event allocated on the kernel stack to
      zero to avert info leak to user space.
      
      Reported-by: syzbot+057458894bc8cada4dee@syzkaller.appspotmail.com
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b06f9d9f
    • Wenwen Wang's avatar
      net: socket: fix a missing-check bug · b6168562
      Wenwen Wang authored
      In ethtool_ioctl(), the ioctl command 'ethcmd' is checked through a switch
      statement to see whether it is necessary to pre-process the ethtool
      structure, because, as mentioned in the comment, the structure
      ethtool_rxnfc is defined with padding. If yes, a user-space buffer 'rxnfc'
      is allocated through compat_alloc_user_space(). One thing to note here is
      that, if 'ethcmd' is ETHTOOL_GRXCLSRLALL, the size of the buffer 'rxnfc' is
      partially determined by 'rule_cnt', which is actually acquired from the
      user-space buffer 'compat_rxnfc', i.e., 'compat_rxnfc->rule_cnt', through
      get_user(). After 'rxnfc' is allocated, the data in the original user-space
      buffer 'compat_rxnfc' is then copied to 'rxnfc' through copy_in_user(),
      including the 'rule_cnt' field. However, after this copy, no check is
      re-enforced on 'rxnfc->rule_cnt'. So it is possible that a malicious user
      race to change the value in the 'compat_rxnfc->rule_cnt' between these two
      copies. Through this way, the attacker can bypass the previous check on
      'rule_cnt' and inject malicious data. This can cause undefined behavior of
      the kernel and introduce potential security risk.
      
      This patch avoids the above issue via copying the value acquired by
      get_user() to 'rxnfc->rule_cn', if 'ethcmd' is ETHTOOL_GRXCLSRLALL.
      Signed-off-by: default avatarWenwen Wang <wang6495@umn.edu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b6168562