1. 29 Sep, 2018 36 commits
    • Takashi Sakamoto's avatar
      ALSA: fireworks: fix memory leak of response buffer at error path · 8e54fc89
      Takashi Sakamoto authored
      commit c3b55e2e upstream.
      
      After allocating memory object for response buffer, ALSA fireworks
      driver has leak of the memory object at error path.
      
      This commit releases the object at the error path.
      
      Fixes: 7d3c1d59('ALSA: fireworks: delayed registration of sound card')
      Cc: <stable@vger.kernel.org> # v4.7+
      Signed-off-by: 's avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8e54fc89
    • Takashi Sakamoto's avatar
      ALSA: firewire-tascam: fix memory leak of private data · e5301d45
      Takashi Sakamoto authored
      commit 8d28277c upstream.
      
      Although private data of sound card instance is usually allocated in the
      tail of the instance, drivers in ALSA firewire stack allocate the private
      data before allocating the instance. In this case, the private data
      should be released explicitly at .private_free callback of the instance.
      
      This commit fixes memory leak following to the above design.
      
      Fixes: b610386c ('ALSA: firewire-tascam: deleyed registration of sound card')
      Cc: <stable@vger.kernel.org> # v4.7+
      Signed-off-by: 's avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e5301d45
    • Takashi Sakamoto's avatar
      ALSA: firewire-digi00x: fix memory leak of private data · 7c57a806
      Takashi Sakamoto authored
      commit a49a83ab upstream.
      
      Although private data of sound card instance is usually allocated in the
      tail of the instance, drivers in ALSA firewire stack allocate the private
      data before allocating the instance. In this case, the private data
      should be released explicitly at .private_free callback of the instance.
      
      This commit fixes memory leak following to the above design.
      
      Fixes: 86c8dd7f ('ALSA: firewire-digi00x: delayed registration of sound card')
      Cc: <stable@vger.kernel.org> # v4.7+
      Signed-off-by: 's avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7c57a806
    • Takashi Sakamoto's avatar
      ALSA: fireface: fix memory leak in ff400_switch_fetching_mode() · e9355495
      Takashi Sakamoto authored
      commit 36f3a6e0 upstream.
      
      An allocated memory forgets to be released.
      
      Fixes: 76fdb3a9 ('ALSA: fireface: add support for Fireface 400')
      Cc: <stable@vger.kernel.org> # 4.12+
      Signed-off-by: 's avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e9355495
    • Willy Tarreau's avatar
      ALSA: emu10k1: fix possible info leak to userspace on SNDRV_EMU10K1_IOCTL_INFO · cedfb9f8
      Willy Tarreau authored
      commit 49434c6c upstream.
      
      snd_emu10k1_fx8010_ioctl(SNDRV_EMU10K1_IOCTL_INFO) allocates
      memory using kmalloc() and partially fills it by calling
      snd_emu10k1_fx8010_info() before returning the resulting
      structure to userspace, leaving uninitialized holes. Let's
      just use kzalloc() here.
      
      BugLink: http://blog.infosectcbr.com.au/2018/09/linux-kernel-infoleaks.htmlSigned-off-by: 's avatarWilly Tarreau <w@1wt.eu>
      Cc: Jann Horn <jannh@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cedfb9f8
    • Takashi Sakamoto's avatar
      ALSA: bebob: use address returned by kmalloc() instead of kernel stack for streaming DMA mapping · c143935a
      Takashi Sakamoto authored
      commit 493626f2 upstream.
      
      When executing 'fw_run_transaction()' with 'TCODE_WRITE_BLOCK_REQUEST',
      an address of 'payload' argument is used for streaming DMA mapping by
      'firewire_ohci' module if 'size' argument is larger than 8 byte.
      Although in this case the address should not be on kernel stack, current
      implementation of ALSA bebob driver uses data in kernel stack for a cue
      to boot M-Audio devices. This often brings unexpected result, especially
      for a case of CONFIG_VMAP_STACK=y.
      
      This commit fixes the bug.
      
      Reference: https://bugzilla.kernel.org/show_bug.cgi?id=201021
      Reference: https://forum.manjaro.org/t/firewire-m-audio-410-driver-wont-load-firmware/51165
      Fixes: a2b2a779('ALSA: bebob: Send a cue to load firmware for M-Audio Firewire series')
      Cc: <stable@vger.kernel.org> # v3.16+
      Signed-off-by: 's avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c143935a
    • Takashi Sakamoto's avatar
      ALSA: bebob: fix memory leak for M-Audio FW1814 and ProjectMix I/O at error path · 28114cae
      Takashi Sakamoto authored
      commit b1fbebd4 upstream.
      
      After allocating model-dependent data for M-Audio FW1814 and ProjectMix
      I/O, ALSA bebob driver has memory leak at error path.
      
      This commit releases the allocated data at the error path.
      
      Fixes: 04a2c73c('ALSA: bebob: delayed registration of sound card')
      Cc: <stable@vger.kernel.org> # v4.7+
      Signed-off-by: 's avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      28114cae
    • Dmitry V. Levin's avatar
      ASoC: uapi: fix sound/skl-tplg-interface.h userspace compilation errors · 30100a47
      Dmitry V. Levin authored
      commit fb504caa upstream.
      
      Include <linux/types.h> and consistently use types it provides
      to fix the following sound/skl-tplg-interface.h userspace compilation errors:
      
      /usr/include/sound/skl-tplg-interface.h:146:2: error: unknown type name 'u32'
        u32 set_params:2;
      /usr/include/sound/skl-tplg-interface.h:147:2: error: unknown type name 'u32'
        u32 rsvd:30;
      /usr/include/sound/skl-tplg-interface.h:148:2: error: unknown type name 'u32'
        u32 param_id;
      /usr/include/sound/skl-tplg-interface.h:149:2: error: unknown type name 'u32'
        u32 max;
      /usr/include/sound/skl-tplg-interface.h:166:2: error: unknown type name 'u16'
        u16 module_id;
      /usr/include/sound/skl-tplg-interface.h:167:2: error: unknown type name 'u16'
        u16 instance_id;
      /usr/include/sound/skl-tplg-interface.h:171:2: error: unknown type name 'u32'
        u32 channels;
      /usr/include/sound/skl-tplg-interface.h:172:2: error: unknown type name 'u32'
        u32 freq;
      /usr/include/sound/skl-tplg-interface.h:173:2: error: unknown type name 'u32'
        u32 bit_depth;
      /usr/include/sound/skl-tplg-interface.h:174:2: error: unknown type name 'u32'
        u32 valid_bit_depth;
      /usr/include/sound/skl-tplg-interface.h:175:2: error: unknown type name 'u32'
        u32 ch_cfg;
      /usr/include/sound/skl-tplg-interface.h:176:2: error: unknown type name 'u32'
        u32 interleaving_style;
      /usr/include/sound/skl-tplg-interface.h:177:2: error: unknown type name 'u32'
        u32 sample_type;
      /usr/include/sound/skl-tplg-interface.h:178:2: error: unknown type name 'u32'
        u32 ch_map;
      /usr/include/sound/skl-tplg-interface.h:182:2: error: unknown type name 'u32'
        u32 set_params:2;
      /usr/include/sound/skl-tplg-interface.h:183:2: error: unknown type name 'u32'
        u32 rsvd:30;
      /usr/include/sound/skl-tplg-interface.h:184:2: error: unknown type name 'u32'
        u32 param_id;
      /usr/include/sound/skl-tplg-interface.h:185:2: error: unknown type name 'u32'
        u32 caps_size;
      /usr/include/sound/skl-tplg-interface.h:186:2: error: unknown type name 'u32'
        u32 caps[HDA_SST_CFG_MAX];
      /usr/include/sound/skl-tplg-interface.h:190:2: error: unknown type name 'u8'
        u8 pipe_id;
      /usr/include/sound/skl-tplg-interface.h:191:2: error: unknown type name 'u8'
        u8 pipe_priority;
      /usr/include/sound/skl-tplg-interface.h:192:2: error: unknown type name 'u16'
        u16 conn_type:4;
      /usr/include/sound/skl-tplg-interface.h:193:2: error: unknown type name 'u16'
        u16 rsvd:4;
      /usr/include/sound/skl-tplg-interface.h:194:2: error: unknown type name 'u16'
        u16 memory_pages:8;
      /usr/include/sound/skl-tplg-interface.h:200:2: error: unknown type name 'u16'
        u16 module_id;
      /usr/include/sound/skl-tplg-interface.h:201:2: error: unknown type name 'u16'
        u16 instance_id;
      /usr/include/sound/skl-tplg-interface.h:202:2: error: unknown type name 'u32'
        u32 max_mcps;
      /usr/include/sound/skl-tplg-interface.h:203:2: error: unknown type name 'u32'
        u32 mem_pages;
      /usr/include/sound/skl-tplg-interface.h:204:2: error: unknown type name 'u32'
        u32 obs;
      /usr/include/sound/skl-tplg-interface.h:205:2: error: unknown type name 'u32'
        u32 ibs;
      /usr/include/sound/skl-tplg-interface.h:206:2: error: unknown type name 'u32'
        u32 vbus_id;
      /usr/include/sound/skl-tplg-interface.h:208:2: error: unknown type name 'u32'
        u32 max_in_queue:8;
      /usr/include/sound/skl-tplg-interface.h:209:2: error: unknown type name 'u32'
        u32 max_out_queue:8;
      /usr/include/sound/skl-tplg-interface.h:210:2: error: unknown type name 'u32'
        u32 time_slot:8;
      /usr/include/sound/skl-tplg-interface.h:211:2: error: unknown type name 'u32'
        u32 core_id:4;
      /usr/include/sound/skl-tplg-interface.h:212:2: error: unknown type name 'u32'
        u32 rsvd1:4;
      /usr/include/sound/skl-tplg-interface.h:214:2: error: unknown type name 'u32'
        u32 module_type:8;
      /usr/include/sound/skl-tplg-interface.h:215:2: error: unknown type name 'u32'
        u32 conn_type:4;
      /usr/include/sound/skl-tplg-interface.h:216:2: error: unknown type name 'u32'
        u32 dev_type:4;
      /usr/include/sound/skl-tplg-interface.h:217:2: error: unknown type name 'u32'
        u32 hw_conn_type:4;
      /usr/include/sound/skl-tplg-interface.h:218:2: error: unknown type name 'u32'
        u32 rsvd2:12;
      /usr/include/sound/skl-tplg-interface.h:220:2: error: unknown type name 'u32'
        u32 params_fixup:8;
      /usr/include/sound/skl-tplg-interface.h:221:2: error: unknown type name 'u32'
        u32 converter:8;
      /usr/include/sound/skl-tplg-interface.h:222:2: error: unknown type name 'u32'
        u32 input_pin_type:1;
      /usr/include/sound/skl-tplg-interface.h:223:2: error: unknown type name 'u32'
        u32 output_pin_type:1;
      /usr/include/sound/skl-tplg-interface.h:224:2: error: unknown type name 'u32'
        u32 is_dynamic_in_pin:1;
      /usr/include/sound/skl-tplg-interface.h:225:2: error: unknown type name 'u32'
        u32 is_dynamic_out_pin:1;
      /usr/include/sound/skl-tplg-interface.h:226:2: error: unknown type name 'u32'
        u32 is_loadable:1;
      /usr/include/sound/skl-tplg-interface.h:227:2: error: unknown type name 'u32'
        u32 rsvd3:11;
      
      Fixes: 0c24fdc0 ("ASoC: topology: Move skl-tplg-interface.h to uapi")
      Signed-off-by: 's avatarDmitry V. Levin <ldv@altlinux.org>
      Reviewed-by: 's avatarGuenter Roeck <groeck@chromium.org>
      Signed-off-by: 's avatarMark Brown <broonie@kernel.org>
      Cc: <stable@vger.kernel.org> # v4.18
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      30100a47
    • Jiada Wang's avatar
      ASoC: rsnd: fixup not to call clk_get/set under non-atomic · 341ff629
      Jiada Wang authored
      commit 4d230d12 upstream.
      
      Clocking operations clk_get/set_rate, are non-atomic,
      they shouldn't be called in soc_pcm_trigger() which is atomic.
      
      Following issue was found due to execution of clk_get_rate() causes
      sleep in soc_pcm_trigger(), which shouldn't be blocked.
      
      We can reproduce this issue by following
      	> enable CONFIG_DEBUG_ATOMIC_SLEEP=y
      	> compile, and boot
      	> mount -t debugfs none /sys/kernel/debug
      	> while true; do cat /sys/kernel/debug/clk/clk_summary > /dev/null; done &
      	> while true; do aplay xxx; done
      
      This patch adds support to .prepare callback, and moves non-atomic
      clocking operations to it. As .prepare is non-atomic, it is always
      called before trigger_start/trigger_stop.
      
      	BUG: sleeping function called from invalid context at kernel/locking/mutex.c:620
      	in_atomic(): 1, irqs_disabled(): 128, pid: 2242, name: aplay
      	INFO: lockdep is turned off.
      	irq event stamp: 5964
      	hardirqs last enabled at (5963): [<ffff200008e59e40>] mutex_lock_nested+0x6e8/0x6f0
      	hardirqs last disabled at (5964): [<ffff200008e623f0>] _raw_spin_lock_irqsave+0x24/0x68
      	softirqs last enabled at (5502): [<ffff200008081838>] __do_softirq+0x560/0x10c0
      	softirqs last disabled at (5495): [<ffff2000080c2e78>] irq_exit+0x160/0x25c
      	Preemption disabled at:[ 62.904063] [<ffff200008be4d48>] snd_pcm_stream_lock+0xb4/0xc0
      	CPU: 2 PID: 2242 Comm: aplay Tainted: G B C 4.9.54+ #186
      	Hardware name: Renesas Salvator-X board based on r8a7795 (DT)
      	Call trace:
      	[<ffff20000808fe48>] dump_backtrace+0x0/0x37c
      	[<ffff2000080901d8>] show_stack+0x14/0x1c
      	[<ffff2000086f4458>] dump_stack+0xfc/0x154
      	[<ffff2000081134a0>] ___might_sleep+0x57c/0x58c
      	[<ffff2000081136b8>] __might_sleep+0x208/0x21c
      	[<ffff200008e5980c>] mutex_lock_nested+0xb4/0x6f0
      	[<ffff2000087cac74>] clk_prepare_lock+0xb0/0x184
      	[<ffff2000087cb094>] clk_core_get_rate+0x14/0x54
      	[<ffff2000087cb0f4>] clk_get_rate+0x20/0x34
      	[<ffff20000113aa00>] rsnd_adg_ssi_clk_try_start+0x158/0x4f8 [snd_soc_rcar]
      	[<ffff20000113da00>] rsnd_ssi_init+0x668/0x7a0 [snd_soc_rcar]
      	[<ffff200001133ff4>] rsnd_soc_dai_trigger+0x4bc/0xcf8 [snd_soc_rcar]
      	[<ffff200008c1af24>] soc_pcm_trigger+0x2a4/0x2d4
      
      Fixes: e7d850dd ("ASoC: rsnd: use mod base common method on SSI-parent")
      Signed-off-by: 's avatarJiada Wang <jiada_wang@mentor.com>
      Signed-off-by: 's avatarTimo Wischer <twischer@de.adit-jv.com>
      [Kuninori: tidyup for upstream]
      Signed-off-by: 's avatarKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Tested-by: 's avatarHiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
      Signed-off-by: 's avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      341ff629
    • Andrew F. Davis's avatar
      ASoC: tas6424: Save last fault register even when clear · 9e6a69b0
      Andrew F. Davis authored
      commit d40e3e9e upstream.
      
      When there is no fault bit set in a fault register we skip the fault
      reporting section for that register. This also skips over saving that
      registers value. We save the value so we will not double report an
      error, but if an error clears then returns we will also not report it
      as we did not save the all cleared register value. Fix this by saving
      the fault register value in the all clear path.
      Signed-off-by: 's avatarAndrew F. Davis <afd@ti.com>
      Signed-off-by: 's avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9e6a69b0
    • Sébastien Szymanski's avatar
      ASoC: cs4265: fix MMTLR Data switch control · df231dbe
      Sébastien Szymanski authored
      commit 90a3b7f8 upstream.
      
      The MMTLR bit is in the CS4265_SPDIF_CTL2 register at address 0x12 bit 0
      and not at address 0x0 bit 1. Fix this.
      Signed-off-by: 's avatarSébastien Szymanski <sebastien.szymanski@armadeus.com>
      Signed-off-by: 's avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      df231dbe
    • Marcel Ziswiler's avatar
      ASoC: wm9712: fix replace codec to component · 401e975e
      Marcel Ziswiler authored
      commit 5e4cfada upstream.
      
      Since commit 143b4484 ("ASoC: wm9712: replace codec to component")
      "wm9712-codec" got renamed to "wm9712-component", however, this change
      never got propagated down to the actual board/platform drivers. E.g. on
      Colibri T20 this lead to the following spew upon boot with sound/touch
      being broken:
      
      [    2.214121] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not registered
      [    2.222137] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
      ...
      [    2.344384] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not registered
      [    2.351885] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
      ...
      [    2.668339] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not registered
      [    2.675811] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
      ...
      [    3.208408] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not registered
      [    3.216312] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
      ...
      [    3.235397] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not registered
      [    3.248938] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
      ...
      [   14.970443] ALSA device list:
      [   14.996628]   No soundcards found.
      
      This commit finally fixes this again.
      Signed-off-by: 's avatarMarcel Ziswiler <marcel.ziswiler@toradex.com>
      Acked-by: 's avatarCharles Keepax <ckeepax@opensource.cirrus.com>
      Signed-off-by: 's avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      401e975e
    • Suren Baghdasaryan's avatar
      NFC: Fix the number of pipes · 58be75ff
      Suren Baghdasaryan authored
      commit e285d5bf upstream.
      
      According to ETSI TS 102 622 specification chapter 4.4 pipe identifier
      is 7 bits long which allows for 128 unique pipe IDs. Because
      NFC_HCI_MAX_PIPES is used as the number of pipes supported and not
      as the max pipe ID, its value should be 128 instead of 127.
      
      nfc_hci_recv_from_llc extracts pipe ID from packet header using
      NFC_HCI_FRAGMENT(0x7F) mask which allows for pipe ID value of 127.
      Same happens when NCI_HCP_MSG_GET_PIPE() is being used. With
      pipes array having only 127 elements and pipe ID of 127 the OOB memory
      access will result.
      
      Cc: Samuel Ortiz <sameo@linux.intel.com>
      Cc: Allen Pais <allen.pais@oracle.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Suggested-by: 's avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: 's avatarSuren Baghdasaryan <surenb@google.com>
      Reviewed-by: 's avatarKees Cook <keescook@chromium.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      58be75ff
    • Suren Baghdasaryan's avatar
      NFC: Fix possible memory corruption when handling SHDLC I-Frame commands · 0ad778ee
      Suren Baghdasaryan authored
      commit 674d9de0 upstream.
      
      When handling SHDLC I-Frame commands "pipe" field used for indexing
      into an array should be checked before usage. If left unchecked it
      might access memory outside of the array of size NFC_HCI_MAX_PIPES(127).
      
      Malformed NFC HCI frames could be injected by a malicious NFC device
      communicating with the device being attacked (remote attack vector),
      or even by an attacker with physical access to the I2C bus such that
      they could influence the data transfers on that bus (local attack vector).
      skb->data is controlled by the attacker and has only been sanitized in
      the most trivial ways (CRC check), therefore we can consider the
      create_info struct and all of its members to tainted. 'create_info->pipe'
      with max value of 255 (uint8) is used to take an offset of the
      hdev->pipes array of 127 elements which can lead to OOB write.
      
      Cc: Samuel Ortiz <sameo@linux.intel.com>
      Cc: Allen Pais <allen.pais@oracle.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Suggested-by: 's avatarKevin Deus <kdeus@google.com>
      Signed-off-by: 's avatarSuren Baghdasaryan <surenb@google.com>
      Acked-by: 's avatarKees Cook <keescook@chromium.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0ad778ee
    • Roopa Prabhu's avatar
      net: rtnl_configure_link: fix dev flags changes arg to __dev_notify_flags · 18b8a9c5
      Roopa Prabhu authored
      [ Upstream commit 56a49d70 ]
      
      This fix addresses https://bugzilla.kernel.org/show_bug.cgi?id=201071
      
      Commit 5025f7f7 wrongly relied on __dev_change_flags to notify users of
      dev flag changes in the case when dev->rtnl_link_state = RTNL_LINK_INITIALIZED.
      Fix it by indicating flag changes explicitly to __dev_notify_flags.
      
      Fixes: 5025f7f7 ("rtnetlink: add rtnl_link_state check in rtnl_configure_link")
      Reported-By: 's avatarLiam mcbirnie <liam.mcbirnie@boeing.com>
      Signed-off-by: 's avatarRoopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      18b8a9c5
    • Antoine Tenart's avatar
      net: mvpp2: let phylink manage the carrier state · 1b469799
      Antoine Tenart authored
      [ Upstream commit 41948ccb ]
      
      Net drivers using phylink shouldn't mess with the link carrier
      themselves and should let phylink manage it. The mvpp2 driver wasn't
      following this best practice as the mac_config() function made calls to
      change the link carrier state. This led to wrongly reported carrier link
      state which then triggered other issues. This patch fixes this
      behaviour.
      
      But the PPv2 driver relied on this misbehaviour in two cases: for fixed
      links and when not using phylink (ACPI mode). The later was fixed by
      adding an explicit call to link_up(), which when the ACPI mode will use
      phylink should be removed.
      
      The fixed link case was relying on the mac_config() function to set the
      link up, as we found an issue in phylink_start() which assumes the
      carrier is off. If not, the link_up() function is never called. To fix
      this, a call to netif_carrier_off() is added just before phylink_start()
      so that we do not introduce a regression in the driver.
      
      Fixes: 4bb04326 ("net: mvpp2: phylink support")
      Reported-by: 's avatarRussell King <linux@armlinux.org.uk>
      Signed-off-by: 's avatarAntoine Tenart <antoine.tenart@bootlin.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1b469799
    • Peter Oskolkov's avatar
      net/ipv6: do not copy dst flags on rt init · 001e4e55
      Peter Oskolkov authored
      [ Upstream commit 30bfd930 ]
      
      DST_NOCOUNT in dst_entry::flags tracks whether the entry counts
      toward route cache size (net->ipv6.sysctl.ip6_rt_max_size).
      
      If the flag is NOT set, dst_ops::pcpuc_entries counter is incremented
      in dist_init() and decremented in dst_destroy().
      
      This flag is tied to allocation/deallocation of dst_entry and
      should not be copied from another dst/route. Otherwise it can happen
      that dst_ops::pcpuc_entries counter grows until no new routes can
      be allocated because the counter reached ip6_rt_max_size due to
      DST_NOCOUNT not set and thus no counter decrements on gc-ed routes.
      
      Fixes: 3b6761d1 ("net/ipv6: Move dst flags to booleans in fib entries")
      Cc: David Ahern <dsahern@gmail.com>
      Acked-by: 's avatarWei Wang <weiwan@google.com>
      Signed-off-by: 's avatarPeter Oskolkov <posk@google.com>
      Reviewed-by: 's avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      001e4e55
    • Xin Long's avatar
      ipv6: use rt6_info members when dst is set in rt6_fill_node · 1328a5a4
      Xin Long authored
      [ Upstream commit 22d0bd82 ]
      
      In inet6_rtm_getroute, since Commit 93531c67 ("net/ipv6: separate
      handling of FIB entries from dst based routes"), it has used rt->from
      to dump route info instead of rt.
      
      However for some route like cache, some of its information like flags
      or gateway is not the same as that of the 'from' one. It caused 'ip
      route get' to dump the wrong route information.
      
      In Jianlin's testing, the output information even lost the expiration
      time for a pmtu route cache due to the wrong fib6_flags.
      
      So change to use rt6_info members for dst addr, src addr, flags and
      gateway when it tries to dump a route entry without fibmatch set.
      
      v1->v2:
        - not use rt6i_prefsrc.
        - also fix the gw dump issue.
      
      Fixes: 93531c67 ("net/ipv6: separate handling of FIB entries from dst based routes")
      Reported-by: 's avatarJianlin Shi <jishi@redhat.com>
      Signed-off-by: 's avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1328a5a4
    • Michael Chan's avatar
      bnxt_en: Fix VF mac address regression. · b5fc7f30
      Michael Chan authored
      [ Upstream commit 28ea334b ]
      
      The recent commit to always forward the VF MAC address to the PF for
      approval may not work if the PF driver or the firmware is older.  This
      will cause the VF driver to fail during probe:
      
        bnxt_en 0000:00:03.0 (unnamed net_device) (uninitialized): hwrm req_type 0xf seq id 0x5 error 0xffff
        bnxt_en 0000:00:03.0 (unnamed net_device) (uninitialized): VF MAC address 00:00:17:02:05:d0 not approved by the PF
        bnxt_en 0000:00:03.0: Unable to initialize mac address.
        bnxt_en: probe of 0000:00:03.0 failed with error -99
      
      We fix it by treating the error as fatal only if the VF MAC address is
      locally generated by the VF.
      
      Fixes: 707e7e96 ("bnxt_en: Always forward VF MAC address to the PF.")
      Reported-by: 's avatarSeth Forshee <seth.forshee@canonical.com>
      Reported-by: 's avatarSiwei Liu <loseweigh@gmail.com>
      Signed-off-by: 's avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b5fc7f30
    • Daniel Borkmann's avatar
      tls: fix currently broken MSG_PEEK behavior · 8ac22b32
      Daniel Borkmann authored
      [ Upstream commit 50c6b58a ]
      
      In kTLS MSG_PEEK behavior is currently failing, strace example:
      
        [pid  2430] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
        [pid  2430] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 4
        [pid  2430] bind(4, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
        [pid  2430] listen(4, 10)               = 0
        [pid  2430] getsockname(4, {sa_family=AF_INET, sin_port=htons(38855), sin_addr=inet_addr("0.0.0.0")}, [16]) = 0
        [pid  2430] connect(3, {sa_family=AF_INET, sin_port=htons(38855), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
        [pid  2430] setsockopt(3, SOL_TCP, 0x1f /* TCP_??? */, [7564404], 4) = 0
        [pid  2430] setsockopt(3, 0x11a /* SOL_?? */, 1, "\3\0033\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 0
        [pid  2430] accept(4, {sa_family=AF_INET, sin_port=htons(49636), sin_addr=inet_addr("127.0.0.1")}, [16]) = 5
        [pid  2430] setsockopt(5, SOL_TCP, 0x1f /* TCP_??? */, [7564404], 4) = 0
        [pid  2430] setsockopt(5, 0x11a /* SOL_?? */, 2, "\3\0033\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 0
        [pid  2430] close(4)                    = 0
        [pid  2430] sendto(3, "test_read_peek", 14, 0, NULL, 0) = 14
        [pid  2430] sendto(3, "_mult_recs\0", 11, 0, NULL, 0) = 11
        [pid  2430] recvfrom(5, "test_read_peektest_read_peektest"..., 64, MSG_PEEK, NULL, NULL) = 64
      
      As can be seen from strace, there are two TLS records sent,
      i) 'test_read_peek' and ii) '_mult_recs\0' where we end up
      peeking 'test_read_peektest_read_peektest'. This is clearly
      wrong, and what happens is that given peek cannot call into
      tls_sw_advance_skb() to unpause strparser and proceed with
      the next skb, we end up looping over the current one, copying
      the 'test_read_peek' over and over into the user provided
      buffer.
      
      Here, we can only peek into the currently held skb (current,
      full TLS record) as otherwise we would end up having to hold
      all the original skb(s) (depending on the peek depth) in a
      separate queue when unpausing strparser to process next
      records, minimally intrusive is to return only up to the
      current record's size (which likely was what c46234eb
      ("tls: RX path for ktls") originally intended as well). Thus,
      after patch we properly peek the first record:
      
        [pid  2046] wait4(2075,  <unfinished ...>
        [pid  2075] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
        [pid  2075] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 4
        [pid  2075] bind(4, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
        [pid  2075] listen(4, 10)               = 0
        [pid  2075] getsockname(4, {sa_family=AF_INET, sin_port=htons(55115), sin_addr=inet_addr("0.0.0.0")}, [16]) = 0
        [pid  2075] connect(3, {sa_family=AF_INET, sin_port=htons(55115), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
        [pid  2075] setsockopt(3, SOL_TCP, 0x1f /* TCP_??? */, [7564404], 4) = 0
        [pid  2075] setsockopt(3, 0x11a /* SOL_?? */, 1, "\3\0033\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 0
        [pid  2075] accept(4, {sa_family=AF_INET, sin_port=htons(45732), sin_addr=inet_addr("127.0.0.1")}, [16]) = 5
        [pid  2075] setsockopt(5, SOL_TCP, 0x1f /* TCP_??? */, [7564404], 4) = 0
        [pid  2075] setsockopt(5, 0x11a /* SOL_?? */, 2, "\3\0033\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 0
        [pid  2075] close(4)                    = 0
        [pid  2075] sendto(3, "test_read_peek", 14, 0, NULL, 0) = 14
        [pid  2075] sendto(3, "_mult_recs\0", 11, 0, NULL, 0) = 11
        [pid  2075] recvfrom(5, "test_read_peek", 64, MSG_PEEK, NULL, NULL) = 14
      
      Fixes: c46234eb ("tls: RX path for ktls")
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8ac22b32
    • Johannes Berg's avatar
      socket: fix struct ifreq size in compat ioctl · 17eef150
      Johannes Berg authored
      [ Upstream commit 1cebf8f1 ]
      
      As reported by Reobert O'Callahan, since Viro's commit to kill
      dev_ifsioc() we attempt to copy too much data in compat mode,
      which may lead to EFAULT when the 32-bit version of struct ifreq
      sits at/near the end of a page boundary, and the next page isn't
      mapped.
      
      Fix this by passing the approprate compat/non-compat size to copy
      and using that, as before the dev_ifsioc() removal. This works
      because only the embedded "struct ifmap" has different size, and
      this is only used in SIOCGIFMAP/SIOCSIFMAP which has a different
      handler. All other parts of the union are naturally compatible.
      
      This fixes https://bugzilla.kernel.org/show_bug.cgi?id=199469.
      
      Fixes: bf440573 ("kill dev_ifsioc()")
      Reported-by: 's avatarRobert O'Callahan <robert@ocallahan.org>
      Signed-off-by: 's avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      17eef150
    • Andrew Lunn's avatar
      net: dsa: mv88e6xxx: Fix ATU Miss Violation · 263baf63
      Andrew Lunn authored
      [ Upstream commit ddca24df ]
      
      Fix a cut/paste error and a typo which results in ATU miss violations
      not being reported.
      
      Fixes: 0977644c ("net: dsa: mv88e6xxx: Decode ATU problem interrupt")
      Signed-off-by: 's avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      263baf63
    • Stephen Hemminger's avatar
      hv_netvsc: fix schedule in RCU context · 4188aa04
      Stephen Hemminger authored
      [ Upstream commit 018349d7 ]
      
      When netvsc device is removed it can call reschedule in RCU context.
      This happens because canceling the subchannel setup work could (in theory)
      cause a reschedule when manipulating the timer.
      
      To reproduce, run with lockdep enabled kernel and unbind
      a network device from hv_netvsc (via sysfs).
      
      [  160.682011] WARNING: suspicious RCU usage
      [  160.707466] 4.19.0-rc3-uio+ #2 Not tainted
      [  160.709937] -----------------------------
      [  160.712352] ./include/linux/rcupdate.h:302 Illegal context switch in RCU read-side critical section!
      [  160.723691]
      [  160.723691] other info that might help us debug this:
      [  160.723691]
      [  160.730955]
      [  160.730955] rcu_scheduler_active = 2, debug_locks = 1
      [  160.762813] 5 locks held by rebind-eth.sh/1812:
      [  160.766851]  #0: 000000008befa37a (sb_writers#6){.+.+}, at: vfs_write+0x184/0x1b0
      [  160.773416]  #1: 00000000b097f236 (&of->mutex){+.+.}, at: kernfs_fop_write+0xe2/0x1a0
      [  160.783766]  #2: 0000000041ee6889 (kn->count#3){++++}, at: kernfs_fop_write+0xeb/0x1a0
      [  160.787465]  #3: 0000000056d92a74 (&dev->mutex){....}, at: device_release_driver_internal+0x39/0x250
      [  160.816987]  #4: 0000000030f6031e (rcu_read_lock){....}, at: netvsc_remove+0x1e/0x250 [hv_netvsc]
      [  160.828629]
      [  160.828629] stack backtrace:
      [  160.831966] CPU: 1 PID: 1812 Comm: rebind-eth.sh Not tainted 4.19.0-rc3-uio+ #2
      [  160.832952] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v1.0 11/26/2012
      [  160.832952] Call Trace:
      [  160.832952]  dump_stack+0x85/0xcb
      [  160.832952]  ___might_sleep+0x1a3/0x240
      [  160.832952]  __flush_work+0x57/0x2e0
      [  160.832952]  ? __mutex_lock+0x83/0x990
      [  160.832952]  ? __kernfs_remove+0x24f/0x2e0
      [  160.832952]  ? __kernfs_remove+0x1b2/0x2e0
      [  160.832952]  ? mark_held_locks+0x50/0x80
      [  160.832952]  ? get_work_pool+0x90/0x90
      [  160.832952]  __cancel_work_timer+0x13c/0x1e0
      [  160.832952]  ? netvsc_remove+0x1e/0x250 [hv_netvsc]
      [  160.832952]  ? __lock_is_held+0x55/0x90
      [  160.832952]  netvsc_remove+0x9a/0x250 [hv_netvsc]
      [  160.832952]  vmbus_remove+0x26/0x30
      [  160.832952]  device_release_driver_internal+0x18a/0x250
      [  160.832952]  unbind_store+0xb4/0x180
      [  160.832952]  kernfs_fop_write+0x113/0x1a0
      [  160.832952]  __vfs_write+0x36/0x1a0
      [  160.832952]  ? rcu_read_lock_sched_held+0x6b/0x80
      [  160.832952]  ? rcu_sync_lockdep_assert+0x2e/0x60
      [  160.832952]  ? __sb_start_write+0x141/0x1a0
      [  160.832952]  ? vfs_write+0x184/0x1b0
      [  160.832952]  vfs_write+0xbe/0x1b0
      [  160.832952]  ksys_write+0x55/0xc0
      [  160.832952]  do_syscall_64+0x60/0x1b0
      [  160.832952]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [  160.832952] RIP: 0033:0x7fe48f4c8154
      
      Resolve this by getting RTNL earlier. This is safe because the subchannel
      work queue does trylock on RTNL and will detect the race.
      
      Fixes: 7b2ee50c ("hv_netvsc: common detach logic")
      Signed-off-by: 's avatarStephen Hemminger <sthemmin@microsoft.com>
      Reviewed-by: 's avatarHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4188aa04
    • Davide Caratti's avatar
      net/sched: act_sample: fix NULL dereference in the data path · 9f248964
      Davide Caratti authored
      [ Upstream commit 34043d25 ]
      
      Matteo reported the following splat, testing the datapath of TC 'sample':
      
       BUG: KASAN: null-ptr-deref in tcf_sample_act+0xc4/0x310
       Read of size 8 at addr 0000000000000000 by task nc/433
      
       CPU: 0 PID: 433 Comm: nc Not tainted 4.19.0-rc3-kvm #17
       Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS ?-20180531_142017-buildhw-08.phx2.fedoraproject.org-1.fc28 04/01/2014
       Call Trace:
        kasan_report.cold.6+0x6c/0x2fa
        tcf_sample_act+0xc4/0x310
        ? dev_hard_start_xmit+0x117/0x180
        tcf_action_exec+0xa3/0x160
        tcf_classify+0xdd/0x1d0
        htb_enqueue+0x18e/0x6b0
        ? deref_stack_reg+0x7a/0xb0
        ? htb_delete+0x4b0/0x4b0
        ? unwind_next_frame+0x819/0x8f0
        ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
        __dev_queue_xmit+0x722/0xca0
        ? unwind_get_return_address_ptr+0x50/0x50
        ? netdev_pick_tx+0xe0/0xe0
        ? save_stack+0x8c/0xb0
        ? kasan_kmalloc+0xbe/0xd0
        ? __kmalloc_track_caller+0xe4/0x1c0
        ? __kmalloc_reserve.isra.45+0x24/0x70
        ? __alloc_skb+0xdd/0x2e0
        ? sk_stream_alloc_skb+0x91/0x3b0
        ? tcp_sendmsg_locked+0x71b/0x15a0
        ? tcp_sendmsg+0x22/0x40
        ? __sys_sendto+0x1b0/0x250
        ? __x64_sys_sendto+0x6f/0x80
        ? do_syscall_64+0x5d/0x150
        ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
        ? __sys_sendto+0x1b0/0x250
        ? __x64_sys_sendto+0x6f/0x80
        ? do_syscall_64+0x5d/0x150
        ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
        ip_finish_output2+0x495/0x590
        ? ip_copy_metadata+0x2e0/0x2e0
        ? skb_gso_validate_network_len+0x6f/0x110
        ? ip_finish_output+0x174/0x280
        __tcp_transmit_skb+0xb17/0x12b0
        ? __tcp_select_window+0x380/0x380
        tcp_write_xmit+0x913/0x1de0
        ? __sk_mem_schedule+0x50/0x80
        tcp_sendmsg_locked+0x49d/0x15a0
        ? tcp_rcv_established+0x8da/0xa30
        ? tcp_set_state+0x220/0x220
        ? clear_user+0x1f/0x50
        ? iov_iter_zero+0x1ae/0x590
        ? __fget_light+0xa0/0xe0
        tcp_sendmsg+0x22/0x40
        __sys_sendto+0x1b0/0x250
        ? __ia32_sys_getpeername+0x40/0x40
        ? _copy_to_user+0x58/0x70
        ? poll_select_copy_remaining+0x176/0x200
        ? __pollwait+0x1c0/0x1c0
        ? ktime_get_ts64+0x11f/0x140
        ? kern_select+0x108/0x150
        ? core_sys_select+0x360/0x360
        ? vfs_read+0x127/0x150
        ? kernel_write+0x90/0x90
        __x64_sys_sendto+0x6f/0x80
        do_syscall_64+0x5d/0x150
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
       RIP: 0033:0x7fefef2b129d
       Code: ff ff ff ff eb b6 0f 1f 80 00 00 00 00 48 8d 05 51 37 0c 00 41 89 ca 8b 00 85 c0 75 20 45 31 c9 45 31 c0 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 6b f3 c3 66 0f 1f 84 00 00 00 00 00 41 56 41
       RSP: 002b:00007fff2f5350c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
       RAX: ffffffffffffffda RBX: 000056118d60c120 RCX: 00007fefef2b129d
       RDX: 0000000000002000 RSI: 000056118d629320 RDI: 0000000000000003
       RBP: 000056118d530370 R08: 0000000000000000 R09: 0000000000000000
       R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000002000
       R13: 000056118d5c2a10 R14: 000056118d5c2a10 R15: 000056118d5303b8
      
      tcf_sample_act() tried to update its per-cpu stats, but tcf_sample_init()
      forgot to allocate them, because tcf_idr_create() was called with a wrong
      value of 'cpustats'. Setting it to true proved to fix the reported crash.
      Reported-by: 's avatarMatteo Croce <mcroce@redhat.com>
      Fixes: 65a206c0 ("net/sched: Change act_api and act_xxx modules to use IDR")
      Fixes: 5c5670fa ("net/sched: Introduce sample tc action")
      Tested-by: 's avatarMatteo Croce <mcroce@redhat.com>
      Signed-off-by: 's avatarDavide Caratti <dcaratti@redhat.com>
      Acked-by: 's avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9f248964
    • Paolo Abeni's avatar
      udp6: add missing checks on edumux packet processing · 1708cc7e
      Paolo Abeni authored
      [ Upstream commit eb63f296 ]
      
      Currently the UDPv6 early demux rx code path lacks some mandatory
      checks, already implemented into the normal RX code path - namely
      the checksum conversion and no_check6_rx check.
      
      Similar to the previous commit, we move the common processing to
      an UDPv6 specific helper and call it from both edemux code path
      and normal code path. In respect to the UDPv4, we need to add an
      explicit check for non zero csum according to no_check6_rx value.
      Reported-by: 's avatarJianlin Shi <jishi@redhat.com>
      Suggested-by: 's avatarXin Long <lucien.xin@gmail.com>
      Fixes: c9f2c1ae ("udp6: fix socket leak on early demux")
      Fixes: 2abb7cdc ("udp: Add support for doing checksum unnecessary conversion")
      Signed-off-by: 's avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1708cc7e
    • Vasily Khoruzhick's avatar
      neighbour: confirm neigh entries when ARP packet is received · c0d10c5d
      Vasily Khoruzhick authored
      [ Upstream commit f0e0d044 ]
      
      Update 'confirmed' timestamp when ARP packet is received. It shouldn't
      affect locktime logic and anyway entry can be confirmed by any higher-layer
      protocol. Thus it makes sense to confirm it when ARP packet is received.
      
      Fixes: 77d71233 ("neighbour: update neigh timestamps iff update is effective")
      Signed-off-by: 's avatarVasily Khoruzhick <vasilykh@arista.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c0d10c5d
    • Sabrina Dubroca's avatar
      tls: clear key material from kernel memory when do_tls_setsockopt_conf fails · 77971ea8
      Sabrina Dubroca authored
      [ Upstream commit c844eb46 ]
      
      Fixes: 3c4d7559 ("tls: kernel TLS support")
      Signed-off-by: 's avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: 's avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      77971ea8
    • Sabrina Dubroca's avatar
      tls: zero the crypto information from tls_context before freeing · 13d1bdc7
      Sabrina Dubroca authored
      [ Upstream commit 86029d10 ]
      
      This contains key material in crypto_send_aes_gcm_128 and
      crypto_recv_aes_gcm_128.
      
      Introduce union tls_crypto_context, and replace the two identical
      unions directly embedded in struct tls_context with it. We can then
      use this union to clean up the memory in the new tls_ctx_free()
      function.
      
      Fixes: 3c4d7559 ("tls: kernel TLS support")
      Signed-off-by: 's avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      13d1bdc7
    • Sabrina Dubroca's avatar
      tls: don't copy the key out of tls12_crypto_info_aes_gcm_128 · d8e6fc73
      Sabrina Dubroca authored
      [ Upstream commit 7cba09c6 ]
      
      There's no need to copy the key to an on-stack buffer before calling
      crypto_aead_setkey().
      
      Fixes: 3c4d7559 ("tls: kernel TLS support")
      Signed-off-by: 's avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d8e6fc73
    • Paolo Abeni's avatar
      udp4: fix IP_CMSG_CHECKSUM for connected sockets · 6d7a3fd5
      Paolo Abeni authored
      [ Upstream commit 2b5a9217 ]
      
      commit 2abb7cdc ("udp: Add support for doing checksum
      unnecessary conversion") left out the early demux path for
      connected sockets. As a result IP_CMSG_CHECKSUM gives wrong
      values for such socket when GRO is not enabled/available.
      
      This change addresses the issue by moving the csum conversion to a
      common helper and using such helper in both the default and the
      early demux rx path.
      
      Fixes: 2abb7cdc ("udp: Add support for doing checksum unnecessary conversion")
      Signed-off-by: 's avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6d7a3fd5
    • Bjørn Mork's avatar
      qmi_wwan: set DTR for modems in forced USB2 mode · a02ff7df
      Bjørn Mork authored
      [ Upstream commit 922005c7 ]
      
      Recent firmware revisions have added the ability to force
      these modems to USB2 mode, hiding their SuperSpeed
      capabilities from the host.  The driver has been using the
      SuperSpeed capability, as shown by the bcdUSB field of the
      device descriptor, to detect the need to enable the DTR
      quirk.  This method fails when the modems are forced to
      USB2 mode by the modem firmware.
      
      Fix by unconditionally enabling the DTR quirk for the
      affected device IDs.
      Reported-by: 's avatarFred Veldini <fred.veldini@gmail.com>
      Reported-by: 's avatarDeshu Wen <dwen@sierrawireless.com>
      Signed-off-by: 's avatarBjørn Mork <bjorn@mork.no>
      Reported-by: 's avatarFred Veldini <fred.veldini@gmail.com>
      Reported-by: 's avatarDeshu Wen <dwen@sierrawireless.com>
      Signed-off-by: 's avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a02ff7df
    • Guillaume Nault's avatar
      pppoe: fix reception of frames with no mac header · 89721b83
      Guillaume Nault authored
      [ Upstream commit 8540827e ]
      
      pppoe_rcv() needs to look back at the Ethernet header in order to
      lookup the PPPoE session. Therefore we need to ensure that the mac
      header is big enough to contain an Ethernet header. Otherwise
      eth_hdr(skb)->h_source might access invalid data.
      
      ==================================================================
      BUG: KMSAN: uninit-value in __get_item drivers/net/ppp/pppoe.c:172 [inline]
      BUG: KMSAN: uninit-value in get_item drivers/net/ppp/pppoe.c:236 [inline]
      BUG: KMSAN: uninit-value in pppoe_rcv+0xcef/0x10e0 drivers/net/ppp/pppoe.c:450
      CPU: 0 PID: 4543 Comm: syz-executor355 Not tainted 4.16.0+ #87
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
      01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:17 [inline]
       dump_stack+0x185/0x1d0 lib/dump_stack.c:53
       kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
       __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
       __get_item drivers/net/ppp/pppoe.c:172 [inline]
       get_item drivers/net/ppp/pppoe.c:236 [inline]
       pppoe_rcv+0xcef/0x10e0 drivers/net/ppp/pppoe.c:450
       __netif_receive_skb_core+0x47df/0x4a90 net/core/dev.c:4562
       __netif_receive_skb net/core/dev.c:4627 [inline]
       netif_receive_skb_internal+0x49d/0x630 net/core/dev.c:4701
       netif_receive_skb+0x230/0x240 net/core/dev.c:4725
       tun_rx_batched drivers/net/tun.c:1555 [inline]
       tun_get_user+0x740f/0x7c60 drivers/net/tun.c:1962
       tun_chr_write_iter+0x1d4/0x330 drivers/net/tun.c:1990
       call_write_iter include/linux/fs.h:1782 [inline]
       new_sync_write fs/read_write.c:469 [inline]
       __vfs_write+0x7fb/0x9f0 fs/read_write.c:482
       vfs_write+0x463/0x8d0 fs/read_write.c:544
       SYSC_write+0x172/0x360 fs/read_write.c:589
       SyS_write+0x55/0x80 fs/read_write.c:581
       do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      RIP: 0033:0x4447c9
      RSP: 002b:00007fff64c8fc28 EFLAGS: 00000297 ORIG_RAX: 0000000000000001
      RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00000000004447c9
      RDX: 000000000000fd87 RSI: 0000000020000600 RDI: 0000000000000004
      RBP: 00000000006cf018 R08: 00007fff64c8fda8 R09: 00007fff00006bda
      R10: 0000000000005fe7 R11: 0000000000000297 R12: 00000000004020d0
      R13: 0000000000402160 R14: 0000000000000000 R15: 0000000000000000
      
      Uninit was created at:
       kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
       kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
       kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
       kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321
       slab_post_alloc_hook mm/slab.h:445 [inline]
       slab_alloc_node mm/slub.c:2737 [inline]
       __kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369
       __kmalloc_reserve net/core/skbuff.c:138 [inline]
       __alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206
       alloc_skb include/linux/skbuff.h:984 [inline]
       alloc_skb_with_frags+0x1d4/0xb20 net/core/skbuff.c:5234
       sock_alloc_send_pskb+0xb56/0x1190 net/core/sock.c:2085
       tun_alloc_skb drivers/net/tun.c:1532 [inline]
       tun_get_user+0x2242/0x7c60 drivers/net/tun.c:1829
       tun_chr_write_iter+0x1d4/0x330 drivers/net/tun.c:1990
       call_write_iter include/linux/fs.h:1782 [inline]
       new_sync_write fs/read_write.c:469 [inline]
       __vfs_write+0x7fb/0x9f0 fs/read_write.c:482
       vfs_write+0x463/0x8d0 fs/read_write.c:544
       SYSC_write+0x172/0x360 fs/read_write.c:589
       SyS_write+0x55/0x80 fs/read_write.c:581
       do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      ==================================================================
      
      Fixes: 224cf5ad ("ppp: Move the PPP drivers")
      Reported-by: syzbot+f5f6080811c849739212@syzkaller.appspotmail.com
      Signed-off-by: 's avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      89721b83
    • Colin Ian King's avatar
      net: hp100: fix always-true check for link up state · b411479d
      Colin Ian King authored
      [ Upstream commit a7f38002 ]
      
      The operation ~(p100_inb(VG_LAN_CFG_1) & HP100_LINK_UP) returns a value
      that is always non-zero and hence the wait for the link to drop always
      terminates prematurely.  Fix this by using a logical not operator instead
      of a bitwise complement.  This issue has been in the driver since
      pre-2.6.12-rc2.
      
      Detected by CoverityScan, CID#114157 ("Logical vs. bitwise operator")
      Signed-off-by: 's avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b411479d
    • Willy Tarreau's avatar
      net/appletalk: fix minor pointer leak to userspace in SIOCFINDIPDDPRT · 6a9c934f
      Willy Tarreau authored
      [ Upstream commit 9824dfae ]
      
      Fields ->dev and ->next of struct ipddp_route may be copied to
      userspace on the SIOCFINDIPDDPRT ioctl. This is only accessible
      to CAP_NET_ADMIN though. Let's manually copy the relevant fields
      instead of using memcpy().
      
      BugLink: http://blog.infosectcbr.com.au/2018/09/linux-kernel-infoleaks.html
      Cc: Jann Horn <jannh@google.com>
      Signed-off-by: 's avatarWilly Tarreau <w@1wt.eu>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6a9c934f
    • Eric Dumazet's avatar
      ipv6: fix possible use-after-free in ip6_xmit() · 6b4d14c5
      Eric Dumazet authored
      [ Upstream commit bbd6528d ]
      
      In the unlikely case ip6_xmit() has to call skb_realloc_headroom(),
      we need to call skb_set_owner_w() before consuming original skb,
      otherwise we risk a use-after-free.
      
      Bring IPv6 in line with what we do in IPv4 to fix this.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: 's avatarEric Dumazet <edumazet@google.com>
      Reported-by: 's avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6b4d14c5
    • Toke Høiland-Jørgensen's avatar
      gso_segment: Reset skb->mac_len after modifying network header · 288942f4
      Toke Høiland-Jørgensen authored
      [ Upstream commit c56cae23 ]
      
      When splitting a GSO segment that consists of encapsulated packets, the
      skb->mac_len of the segments can end up being set wrong, causing packet
      drops in particular when using act_mirred and ifb interfaces in
      combination with a qdisc that splits GSO packets.
      
      This happens because at the time skb_segment() is called, network_header
      will point to the inner header, throwing off the calculation in
      skb_reset_mac_len(). The network_header is subsequently adjust by the
      outer IP gso_segment handlers, but they don't set the mac_len.
      
      Fix this by adding skb_reset_mac_len() calls to both the IPv4 and IPv6
      gso_segment handlers, after they modify the network_header.
      
      Many thanks to Eric Dumazet for his help in identifying the cause of
      the bug.
      Acked-by: 's avatarDave Taht <dave.taht@gmail.com>
      Reviewed-by: 's avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: 's avatarToke Høiland-Jørgensen <toke@toke.dk>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      288942f4
  2. 26 Sep, 2018 4 commits