linux-stable.git/drivers/staging, branch v4.19.151 Linux kernel stable tree staging:r8188eu: avoid skb_clone for amsdu to msdu conversion 2020-10-01T11:14:43+00:00 Ivan Safonov insafonov@gmail.com 2020-04-23T19:14:04+00:00 bbd1347bd4ad6e2fc79bed8f19b088abb42fb4b1 [ Upstream commit 628cbd971a927abe6388d44320e351c337b331e4 ] skb clones use same data buffer, so tail of one skb is corrupted by beginning of next skb. Signed-off-by: Ivan Safonov <insafonov@gmail.com> Link: https://lore.kernel.org/r/20200423191404.12028-1-insafonov@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 628cbd971a927abe6388d44320e351c337b331e4 ]

skb clones use same data buffer,
so tail of one skb is corrupted by beginning of next skb.

Signed-off-by: Ivan Safonov <insafonov@gmail.com>
Link: https://lore.kernel.org/r/20200423191404.12028-1-insafonov@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
media: staging/imx: Missing assignment in imx_media_capture_device_register() 2020-10-01T11:14:34+00:00 Dan Carpenter dan.carpenter@oracle.com 2020-02-11T07:35:46+00:00 eec0eacf6c098492adc560429faa484e0d81829d [ Upstream commit ef0ed05dcef8a74178a8b480cce23a377b1de2b8 ] There was supposed to be a "ret = " assignment here, otherwise the error handling on the next line won't work. Fixes: 64b5a49df486 ("[media] media: imx: Add Capture Device Interface") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Steve Longerbeam <slongerbeam@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit ef0ed05dcef8a74178a8b480cce23a377b1de2b8 ]

There was supposed to be a "ret = " assignment here, otherwise the
error handling on the next line won't work.

Fixes: 64b5a49df486 ("[media] media: imx: Add Capture Device Interface")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Steve Longerbeam <slongerbeam@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
staging: greybus: audio: fix uninitialized value issue 2020-09-17T11:45:30+00:00 Vaibhav Agarwal vaibhav.sr@gmail.com 2020-08-14T12:33:15+00:00 72cd9c802a69fafe0537dda450ffb452673188cf commit 1dffeb8b8b4c261c45416d53c75ea51e6ece1770 upstream. The current implementation for gbcodec_mixer_dapm_ctl_put() uses uninitialized gbvalue for comparison with updated value. This was found using static analysis with coverity. Uninitialized scalar variable (UNINIT) 11. uninit_use: Using uninitialized value gbvalue.value.integer_value[0]. 460 if (gbvalue.value.integer_value[0] != val) { This patch fixes the issue with fetching the gbvalue before using it for comparision. Fixes: 6339d2322c47 ("greybus: audio: Add topology parser for GB codec") Reported-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Vaibhav Agarwal <vaibhav.sr@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/bc4f29eb502ccf93cd2ffd98db0e319fa7d0f247.1597408126.git.vaibhav.sr@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 1dffeb8b8b4c261c45416d53c75ea51e6ece1770 upstream.

The current implementation for gbcodec_mixer_dapm_ctl_put() uses
uninitialized gbvalue for comparison with updated value. This was found
using static analysis with coverity.

Uninitialized scalar variable (UNINIT)
11. uninit_use: Using uninitialized value
gbvalue.value.integer_value[0].
460        if (gbvalue.value.integer_value[0] != val) {

This patch fixes the issue with fetching the gbvalue before using it for
    comparision.

Fixes: 6339d2322c47 ("greybus: audio: Add topology parser for GB codec")
Reported-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Vaibhav Agarwal <vaibhav.sr@gmail.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/bc4f29eb502ccf93cd2ffd98db0e319fa7d0f247.1597408126.git.vaibhav.sr@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: wlan-ng: fix out of bounds read in prism2sta_probe_usb() 2020-09-17T11:45:28+00:00 Rustam Kovhaev rkovhaev@gmail.com 2020-08-04T14:56:14+00:00 0a0b6ac0e4b2102c0c6fa673793b1409405bbbea commit fea22e159d51c766ba70473f473a0ec914cc7e92 upstream. let's use usb_find_common_endpoints() to discover endpoints, it does all necessary checks for type and xfer direction remove memset() in hfa384x_create(), because we now assign endpoints in prism2sta_probe_usb() and because create_wlan() uses kzalloc() to allocate hfa384x struct before calling hfa384x_create() Fixes: faaff9765664 ("staging: wlan-ng: properly check endpoint types") Reported-and-tested-by: syzbot+22794221ab96b0bab53a@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=22794221ab96b0bab53a Signed-off-by: Rustam Kovhaev <rkovhaev@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200804145614.104320-1-rkovhaev@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit fea22e159d51c766ba70473f473a0ec914cc7e92 upstream.

let's use usb_find_common_endpoints() to discover endpoints, it does all
necessary checks for type and xfer direction

remove memset() in hfa384x_create(), because we now assign endpoints in
prism2sta_probe_usb() and because create_wlan() uses kzalloc() to
allocate hfa384x struct before calling hfa384x_create()

Fixes: faaff9765664 ("staging: wlan-ng: properly check endpoint types")
Reported-and-tested-by: syzbot+22794221ab96b0bab53a@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=22794221ab96b0bab53a
Signed-off-by: Rustam Kovhaev <rkovhaev@gmail.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200804145614.104320-1-rkovhaev@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: rtl8192u: fix a dubious looking mask before a shift 2020-08-19T06:14:58+00:00 Colin Ian King colin.king@canonical.com 2020-07-16T15:47:20+00:00 8b26055ccdc02047e39caa128e65add116b29525 [ Upstream commit c4283950a9a4d3bf4a3f362e406c80ab14f10714 ] Currently the masking of ret with 0xff and followed by a right shift of 8 bits always leaves a zero result. It appears the mask of 0xff is incorrect and should be 0xff00, but I don't have the hardware to test this. Fix this to mask the upper 8 bits before shifting. [ Not tested ] Addresses-Coverity: ("Operands don't affect result") Fixes: 8fc8598e61f6 ("Staging: Added Realtek rtl8192u driver to staging") Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20200716154720.1710252-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit c4283950a9a4d3bf4a3f362e406c80ab14f10714 ]

Currently the masking of ret with 0xff and followed by a right shift
of 8 bits always leaves a zero result.  It appears the mask of 0xff
is incorrect and should be 0xff00, but I don't have the hardware to
test this. Fix this to mask the upper 8 bits before shifting.

[ Not tested ]

Addresses-Coverity: ("Operands don't affect result")
Fixes: 8fc8598e61f6 ("Staging: Added Realtek rtl8192u driver to staging")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20200716154720.1710252-1-colin.king@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
staging: android: ashmem: Fix lockdep warning for write operation 2020-08-11T13:32:31+00:00 Suren Baghdasaryan surenb@google.com 2020-07-30T19:26:32+00:00 fbe7e878fea059fb536ac55a8ec7fe72433a95dd commit 3e338d3c95c735dc3265a86016bb4c022ec7cadc upstream. syzbot report [1] describes a deadlock when write operation against an ashmem fd executed at the time when ashmem is shrinking its cache results in the following lock sequence: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim); lock(&sb->s_type->i_mutex_key#13); lock(fs_reclaim); lock(&sb->s_type->i_mutex_key#13); kswapd takes fs_reclaim and then inode_lock while generic_perform_write takes inode_lock and then fs_reclaim. However ashmem does not support writing into backing shmem with a write syscall. The only way to change its content is to mmap it and operate on mapped memory. Therefore the race that lockdep is warning about is not valid. Resolve this by introducing a separate lockdep class for the backing shmem inodes. [1]: https://lkml.kernel.org/lkml/0000000000000b5f9d059aa2037f@google.com/ Reported-by: syzbot+7a0d9d0b26efefe61780@syzkaller.appspotmail.com Signed-off-by: Suren Baghdasaryan <surenb@google.com> Cc: stable <stable@vger.kernel.org> Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org> Link: https://lore.kernel.org/r/20200730192632.3088194-1-surenb@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 3e338d3c95c735dc3265a86016bb4c022ec7cadc upstream.

syzbot report [1] describes a deadlock when write operation against an
ashmem fd executed at the time when ashmem is shrinking its cache results
in the following lock sequence:

Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(fs_reclaim);
                                lock(&sb->s_type->i_mutex_key#13);
                                lock(fs_reclaim);
   lock(&sb->s_type->i_mutex_key#13);

kswapd takes fs_reclaim and then inode_lock while generic_perform_write
takes inode_lock and then fs_reclaim. However ashmem does not support
writing into backing shmem with a write syscall. The only way to change
its content is to mmap it and operate on mapped memory. Therefore the race
that lockdep is warning about is not valid. Resolve this by introducing a
separate lockdep class for the backing shmem inodes.

[1]: https://lkml.kernel.org/lkml/0000000000000b5f9d059aa2037f@google.com/

Reported-by: syzbot+7a0d9d0b26efefe61780@syzkaller.appspotmail.com
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
Link: https://lore.kernel.org/r/20200730192632.3088194-1-surenb@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: comedi: addi_apci_1564: check INSN_CONFIG_DIGITAL_TRIG shift 2020-07-29T08:16:56+00:00 Ian Abbott abbotti@mev.co.uk 2020-07-17T14:52:56+00:00 f96ab42f29656efef6cd3cb1a68d8757e4286df1 commit 926234f1b8434c4409aa4c53637aa3362ca07cea upstream. The `INSN_CONFIG` comedi instruction with sub-instruction code `INSN_CONFIG_DIGITAL_TRIG` includes a base channel in `data[3]`. This is used as a right shift amount for other bitmask values without being checked. Shift amounts greater than or equal to 32 will result in undefined behavior. Add code to deal with this. Fixes: 1e15687ea472 ("staging: comedi: addi_apci_1564: add Change-of-State interrupt subdevice and required functions") Cc: <stable@vger.kernel.org> #3.17+ Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Link: https://lore.kernel.org/r/20200717145257.112660-4-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 926234f1b8434c4409aa4c53637aa3362ca07cea upstream.

The `INSN_CONFIG` comedi instruction with sub-instruction code
`INSN_CONFIG_DIGITAL_TRIG` includes a base channel in `data[3]`. This is
used as a right shift amount for other bitmask values without being
checked.  Shift amounts greater than or equal to 32 will result in
undefined behavior.  Add code to deal with this.

Fixes: 1e15687ea472 ("staging: comedi: addi_apci_1564: add Change-of-State interrupt subdevice and required functions")
Cc: <stable@vger.kernel.org> #3.17+
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://lore.kernel.org/r/20200717145257.112660-4-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: comedi: addi_apci_1500: check INSN_CONFIG_DIGITAL_TRIG shift 2020-07-29T08:16:56+00:00 Ian Abbott abbotti@mev.co.uk 2020-07-17T14:52:57+00:00 3027b255ebfbce099279f9dc0ae16448a5966dad commit fc846e9db67c7e808d77bf9e2ef3d49e3820ce5d upstream. The `INSN_CONFIG` comedi instruction with sub-instruction code `INSN_CONFIG_DIGITAL_TRIG` includes a base channel in `data[3]`. This is used as a right shift amount for other bitmask values without being checked. Shift amounts greater than or equal to 32 will result in undefined behavior. Add code to deal with this, adjusting the checks for invalid channels so that enabled channel bits that would have been lost by shifting are also checked for validity. Only channels 0 to 15 are valid. Fixes: a8c66b684efaf ("staging: comedi: addi_apci_1500: rewrite the subdevice support functions") Cc: <stable@vger.kernel.org> #4.0+: ef75e14a6c93: staging: comedi: verify array index is correct before using it Cc: <stable@vger.kernel.org> #4.0+ Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Link: https://lore.kernel.org/r/20200717145257.112660-5-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit fc846e9db67c7e808d77bf9e2ef3d49e3820ce5d upstream.

The `INSN_CONFIG` comedi instruction with sub-instruction code
`INSN_CONFIG_DIGITAL_TRIG` includes a base channel in `data[3]`. This is
used as a right shift amount for other bitmask values without being
checked.  Shift amounts greater than or equal to 32 will result in
undefined behavior.  Add code to deal with this, adjusting the checks
for invalid channels so that enabled channel bits that would have been
lost by shifting are also checked for validity.  Only channels 0 to 15
are valid.

Fixes: a8c66b684efaf ("staging: comedi: addi_apci_1500: rewrite the subdevice support functions")
Cc: <stable@vger.kernel.org> #4.0+: ef75e14a6c93: staging: comedi: verify array index is correct before using it
Cc: <stable@vger.kernel.org> #4.0+
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://lore.kernel.org/r/20200717145257.112660-5-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: comedi: ni_6527: fix INSN_CONFIG_DIGITAL_TRIG support 2020-07-29T08:16:55+00:00 Ian Abbott abbotti@mev.co.uk 2020-07-17T14:52:54+00:00 8f6e8ce1dbb240314b56a9cd57c2a6249ce9522e commit f07804ec77d77f8a9dcf570a24154e17747bc82f upstream. `ni6527_intr_insn_config()` processes `INSN_CONFIG` comedi instructions for the "interrupt" subdevice. When `data[0]` is `INSN_CONFIG_DIGITAL_TRIG` it is configuring the digital trigger. When `data[2]` is `COMEDI_DIGITAL_TRIG_ENABLE_EDGES` it is configuring rising and falling edge detection for the digital trigger, using a base channel number (or shift amount) in `data[3]`, a rising edge bitmask in `data[4]` and falling edge bitmask in `data[5]`. If the base channel number (shift amount) is greater than or equal to the number of channels (24) of the digital input subdevice, there are no changes to the rising and falling edges, so the mask of channels to be changed can be set to 0, otherwise the mask of channels to be changed, and the rising and falling edge bitmasks are shifted by the base channel number before calling `ni6527_set_edge_detection()` to change the appropriate registers. Unfortunately, the code is comparing the base channel (shift amount) to the interrupt subdevice's number of channels (1) instead of the digital input subdevice's number of channels (24). Fix it by comparing to 32 because all shift amounts for an `unsigned int` must be less than that and everything from bit 24 upwards is ignored by `ni6527_set_edge_detection()` anyway. Fixes: 110f9e687c1a8 ("staging: comedi: ni_6527: support INSN_CONFIG_DIGITAL_TRIG") Cc: <stable@vger.kernel.org> # 3.17+ Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Link: https://lore.kernel.org/r/20200717145257.112660-2-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit f07804ec77d77f8a9dcf570a24154e17747bc82f upstream.

`ni6527_intr_insn_config()` processes `INSN_CONFIG` comedi instructions
for the "interrupt" subdevice.  When `data[0]` is
`INSN_CONFIG_DIGITAL_TRIG` it is configuring the digital trigger.  When
`data[2]` is `COMEDI_DIGITAL_TRIG_ENABLE_EDGES` it is configuring rising
and falling edge detection for the digital trigger, using a base channel
number (or shift amount) in `data[3]`, a rising edge bitmask in
`data[4]` and falling edge bitmask in `data[5]`.

If the base channel number (shift amount) is greater than or equal to
the number of channels (24) of the digital input subdevice, there are no
changes to the rising and falling edges, so the mask of channels to be
changed can be set to 0, otherwise the mask of channels to be changed,
and the rising and falling edge bitmasks are shifted by the base channel
number before calling `ni6527_set_edge_detection()` to change the
appropriate registers.  Unfortunately, the code is comparing the base
channel (shift amount) to the interrupt subdevice's number of channels
(1) instead of the digital input subdevice's number of channels (24).
Fix it by comparing to 32 because all shift amounts for an `unsigned
int` must be less than that and everything from bit 24 upwards is
ignored by `ni6527_set_edge_detection()` anyway.

Fixes: 110f9e687c1a8 ("staging: comedi: ni_6527: support INSN_CONFIG_DIGITAL_TRIG")
Cc: <stable@vger.kernel.org> # 3.17+
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://lore.kernel.org/r/20200717145257.112660-2-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: comedi: addi_apci_1032: check INSN_CONFIG_DIGITAL_TRIG shift 2020-07-29T08:16:55+00:00 Ian Abbott abbotti@mev.co.uk 2020-07-17T14:52:55+00:00 97ab1fd6d47f2f3c66b4f8e221e440fdd348cb14 commit 0bd0db42a030b75c20028c7ba6e327b9cb554116 upstream. The `INSN_CONFIG` comedi instruction with sub-instruction code `INSN_CONFIG_DIGITAL_TRIG` includes a base channel in `data[3]`. This is used as a right shift amount for other bitmask values without being checked. Shift amounts greater than or equal to 32 will result in undefined behavior. Add code to deal with this. Fixes: 33cdce6293dcc ("staging: comedi: addi_apci_1032: conform to new INSN_CONFIG_DIGITAL_TRIG") Cc: <stable@vger.kernel.org> #3.8+ Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Link: https://lore.kernel.org/r/20200717145257.112660-3-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 0bd0db42a030b75c20028c7ba6e327b9cb554116 upstream.

The `INSN_CONFIG` comedi instruction with sub-instruction code
`INSN_CONFIG_DIGITAL_TRIG` includes a base channel in `data[3]`. This is
used as a right shift amount for other bitmask values without being
checked.  Shift amounts greater than or equal to 32 will result in
undefined behavior.  Add code to deal with this.

Fixes: 33cdce6293dcc ("staging: comedi: addi_apci_1032: conform to new INSN_CONFIG_DIGITAL_TRIG")
Cc: <stable@vger.kernel.org> #3.8+
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://lore.kernel.org/r/20200717145257.112660-3-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>