aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/staging
AgeCommit message (Collapse)Author
2021-06-03staging: emxx_udc: fix loop in _nbu2ss_nuke()Dan Carpenter
[ Upstream commit e0112a7c9e847ada15a631b88e279d547e8f26a7 ] The _nbu2ss_ep_done() function calls: list_del_init(&req->queue); which means that the loop will never exit. Fixes: ca3d253eb967 ("Staging: emxx_udc: Iterate list using list_for_each_entry") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/YKUd0sDyjm/lkJfJ@mwanda Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-06-03spi: mt7621: Don't leak SPI master in probe error pathLukas Wunner
commit 46b5c4fb87ce8211e0f9b0383dbde72c3652d2ba upstream. If the calls to device_reset() or devm_spi_register_controller() fail on probe of the MediaTek MT7621 SPI driver, the spi_controller struct is erroneously not freed. Fix by switching over to the new devm_spi_alloc_master() helper. Additionally, there's an ordering issue in mt7621_spi_remove() wherein the spi_controller is unregistered after disabling the SYS clock. The correct order is to call spi_unregister_controller() *before* this teardown step because bus accesses may still be ongoing until that function returns. All of these bugs have existed since the driver was first introduced, so it seems fair to fix them together in a single commit. Fixes: 1ab7f2a43558 ("staging: mt7621-spi: add mt7621 support") Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Stefan Roese <sr@denx.de> Cc: <stable@vger.kernel.org> # v4.17+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation Cc: <stable@vger.kernel.org> # v4.17+ Link: https://lore.kernel.org/r/72b680796149f5fcda0b3f530ffb7ee73b04f224.1607286887.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org> [lukas: backport to v4.19.192] Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-03spi: mt7621: Disable clock in probe error pathLukas Wunner
commit 24f7033405abe195224ec793dbc3d7a27dec0b98 upstream. Commit 702b15cb9712 ("spi: mt7621: fix missing clk_disable_unprepare() on error in mt7621_spi_probe") sought to disable the SYS clock on probe errors, but only did so for 2 of 3 potentially failing calls: The clock needs to be disabled on failure of devm_spi_register_controller() as well. Moreover, the commit purports to fix a bug in commit cbd66c626e16 ("spi: mt7621: Move SPI driver out of staging") but in reality the bug has existed since the driver was first introduced. Fixes: 1ab7f2a43558 ("staging: mt7621-spi: add mt7621 support") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: <stable@vger.kernel.org> # v4.17+: 702b15cb9712: spi: mt7621: fix missing clk_disable_unprepare() on error in mt7621_spi_probe Cc: <stable@vger.kernel.org> # v4.17+ Cc: Qinglang Miao <miaoqinglang@huawei.com> Link: https://lore.kernel.org/r/36ad42760087952fb7c10aae7d2628547c26a7ec.1607286887.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org> [lukas: backport to v4.19.192] Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-03staging: iio: cdc: ad7746: avoid overwrite of num_channelsLucas Stankus
commit 04f5b9f539ce314f758d919a14dc7a669f3b7838 upstream. AD7745 devices don't have the CIN2 pins and therefore can't handle related channels. Forcing the number of AD7746 channels may lead to enabling more channels than what the hardware actually supports. Avoid num_channels being overwritten after first assignment. Signed-off-by: Lucas Stankus <lucas.p.stankus@gmail.com> Fixes: 83e416f458d53 ("staging: iio: adc: Replace, rewrite ad7745 from scratch.") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-22media: omap4iss: return error code when omap4iss_get() failedYang Yingliang
[ Upstream commit 8938c48fa25b491842ece9eb38f0bea0fcbaca44 ] If omap4iss_get() failed, it need return error code in iss_probe(). Fixes: 59f0ad807681 ("[media] v4l: omap4iss: Add support for OMAP4...") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.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>
2021-05-22staging: greybus: uart: fix unprivileged TIOCCSERIALJohan Hovold
[ Upstream commit 60c6b305c11b5fd167ce5e2ce42f3a9098c388f0 ] TIOCSSERIAL is a horrid, underspecified, legacy interface which for most serial devices is only useful for setting the close_delay and closing_wait parameters. A non-privileged user has only ever been able to set the since long deprecated ASYNC_SPD flags and trying to change any other *supported* feature should result in -EPERM being returned. Setting the current values for any supported features should return success. Fix the greybus implementation which instead indicated that the TIOCSSERIAL ioctl was not even implemented when a non-privileged user set the current values. Fixes: e68453ed28c5 ("greybus: uart-gb: now builds, more framework added") Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210407102334.32361-7-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-22staging: rtl8192u: Fix potential infinite loopColin Ian King
[ Upstream commit f9b9263a25dc3d2eaaa829e207434db6951ca7bc ] The for-loop iterates with a u8 loop counter i and compares this with the loop upper limit of riv->ieee80211->LinkDetectInfo.SlotNum that is a u16 type. There is a potential infinite loop if SlotNum is larger than the u8 loop counter. Fix this by making the loop counter the same type as SlotNum. Addresses-Coverity: ("Infinite loop") 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/20210407150308.496623-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-22erofs: add unsupported inode i_format checkGao Xiang
commit 24a806d849c0b0c1d0cd6a6b93ba4ae4c0ec9f08 upstream. If any unknown i_format fields are set (may be of some new incompat inode features), mark such inode as unsupported. Just in case of any new incompat i_format fields added in the future. Link: https://lore.kernel.org/r/20210329003614.6583-1-hsiangkao@aol.com Fixes: 431339ba9042 ("staging: erofs: add inode operations") Cc: <stable@vger.kernel.org> # 4.19+ Signed-off-by: Gao Xiang <hsiangkao@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-07erofs: fix extended inode could cross boundaryGao Xiang
commit 0dcd3c94e02438f4a571690e26f4ee997524102a upstream. Each ondisk inode should be aligned with inode slot boundary (32-byte alignment) because of nid calculation formula, so all compact inodes (32 byte) cannot across page boundary. However, extended inode is now 64-byte form, which can across page boundary in principle if the location is specified on purpose, although it's hard to be generated by mkfs due to the allocation policy and rarely used by Android use case now mainly for > 4GiB files. For now, only two fields `i_ctime_nsec` and `i_nlink' couldn't be read from disk properly and cause out-of-bound memory read with random value. Let's fix now. Fixes: 431339ba9042 ("staging: erofs: add inode operations") Cc: <stable@vger.kernel.org> # 4.19+ Link: https://lore.kernel.org/r/20200729175801.GA23973@xiangao.remote.csb Reviewed-by: Chao Yu <yuchao0@huawei.com> Signed-off-by: Gao Xiang <hsiangkao@redhat.com> [ Gao Xiang: resolve non-trivial conflicts for latest 4.19.y. ] Signed-off-by: Gao Xiang <hsiangkao@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-16staging: m57621-mmc: delete driver from the tree.Greg Kroah-Hartman
[ Upstream commit 441bf7332d55c4d34afae9ffc3bbec621093f4d1 ] The license text in this driver is "interesting" and not really obvious that it is supposed to be able to be distributed in the kernel source tree. Yes, the MODULE_LICENSE() text says GPL, so it's probably ok, but to be safe, I am deleting this driver. I will be glad to add it back if the license is properly sorted out, but for now, this isn't worth the potential risk, I should have never taken it in the first place. Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: NeilBrown <neil@brown.name> Cc: George Hilliard <thirtythreeforty@gmail.com> Cc: "Christian Lütke-Stetzkamp" <christian@lkamp.de> Cc: Nishad Kamdar <nishadkamdar@gmail.com> Cc: Sergej Perschin <ser.perschin@gmail.com> Cc: John Crispin <blogic@openwrt.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-04-07staging: rtl8192e: Change state information from u16 to u8Atul Gopinathan
commit e78836ae76d20f38eed8c8c67f21db97529949da upstream. The "u16 CcxRmState[2];" array field in struct "rtllib_network" has 4 bytes in total while the operations performed on this array through-out the code base are only 2 bytes. The "CcxRmState" field is fed only 2 bytes of data using memcpy(): (In rtllib_rx.c:1972) memcpy(network->CcxRmState, &info_element->data[4], 2) With "info_element->data[]" being a u8 array, if 2 bytes are written into "CcxRmState" (whose one element is u16 size), then the 2 u8 elements from "data[]" gets squashed and written into the first element ("CcxRmState[0]") while the second element ("CcxRmState[1]") is never fed with any data. Same in file rtllib_rx.c:2522: memcpy(dst->CcxRmState, src->CcxRmState, 2); The above line duplicates "src" data to "dst" but only writes 2 bytes (and not 4, which is the actual size). Again, only 1st element gets the value while the 2nd element remains uninitialized. This later makes operations done with CcxRmState unpredictable in the following lines as the 1st element is having a squashed number while the 2nd element is having an uninitialized random number. rtllib_rx.c:1973: if (network->CcxRmState[0] != 0) rtllib_rx.c:1977: network->MBssidMask = network->CcxRmState[1] & 0x07; network->MBssidMask is also of type u8 and not u16. Fix this by changing the type of "CcxRmState" from u16 to u8 so that the data written into this array and read from it make sense and are not random values. NOTE: The wrong initialization of "CcxRmState" can be seen in the following commit: commit ecdfa44610fa ("Staging: add Realtek 8192 PCI wireless driver") The above commit created a file `rtl8192e/ieee80211.h` which used to have the faulty line. The file has been deleted (or possibly renamed) with the contents copied in to a new file `rtl8192e/rtllib.h` along with additional code in the commit 94a799425eee (tagged in Fixes). Fixes: 94a799425eee ("From: wlanfae <wlanfae@realtek.com> [PATCH 1/8] rtl8192e: Import new version of driver from realtek") Cc: stable@vger.kernel.org Signed-off-by: Atul Gopinathan <atulgopinathan@gmail.com> Link: https://lore.kernel.org/r/20210323113413.29179-2-atulgopinathan@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-07staging: rtl8192e: Fix incorrect source in memcpy()Atul Gopinathan
commit 72ad25fbbb78930f892b191637359ab5b94b3190 upstream. The variable "info_element" is of the following type: struct rtllib_info_element *info_element defined in drivers/staging/rtl8192e/rtllib.h: struct rtllib_info_element { u8 id; u8 len; u8 data[]; } __packed; The "len" field defines the size of the "data[]" array. The code is supposed to check if "info_element->len" is greater than 4 and later equal to 6. If this is satisfied then, the last two bytes (the 4th and 5th element of u8 "data[]" array) are copied into "network->CcxRmState". Right now the code uses "memcpy()" with the source as "&info_element[4]" which would copy in wrong and unintended information. The struct "rtllib_info_element" has a size of 2 bytes for "id" and "len", therefore indexing will be done in interval of 2 bytes. So, "info_element[4]" would point to data which is beyond the memory allocated for this pointer (that is, at x+8, while "info_element" has been allocated only from x to x+7 (2 + 6 => 8 bytes)). This patch rectifies this error by using "&info_element->data[4]" which correctly copies the last two bytes of "data[]". NOTE: The faulty line of code came from the following commit: commit ecdfa44610fa ("Staging: add Realtek 8192 PCI wireless driver") The above commit created the file `rtl8192e/ieee80211/ieee80211_rx.c` which had the faulty line of code. This file has been deleted (or possibly renamed) with the contents copied in to a new file `rtl8192e/rtllib_rx.c` along with additional code in the commit 94a799425eee (tagged in Fixes). Fixes: 94a799425eee ("From: wlanfae <wlanfae@realtek.com> [PATCH 1/8] rtl8192e: Import new version of driver from realtek") Cc: stable@vger.kernel.org Signed-off-by: Atul Gopinathan <atulgopinathan@gmail.com> Link: https://lore.kernel.org/r/20210323113413.29179-1-atulgopinathan@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-07staging: comedi: cb_pcidas64: fix request_irq() warnTong Zhang
[ Upstream commit d2d106fe3badfc3bf0dd3899d1c3f210c7203eab ] request_irq() wont accept a name which contains slash so we need to repalce it with something else -- otherwise it will trigger a warning and the entry in /proc/irq/ will not be created since the .name might be used by userspace and we don't want to break userspace, so we are changing the parameters passed to request_irq() [ 1.565966] name 'pci-das6402/16' [ 1.566149] WARNING: CPU: 0 PID: 184 at fs/proc/generic.c:180 __xlate_proc_name+0x93/0xb0 [ 1.568923] RIP: 0010:__xlate_proc_name+0x93/0xb0 [ 1.574200] Call Trace: [ 1.574722] proc_mkdir+0x18/0x20 [ 1.576629] request_threaded_irq+0xfe/0x160 [ 1.576859] auto_attach+0x60a/0xc40 [cb_pcidas64] Suggested-by: Ian Abbott <abbotti@mev.co.uk> Reviewed-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Tong Zhang <ztong0001@gmail.com> Link: https://lore.kernel.org/r/20210315195814.4692-1-ztong0001@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-04-07staging: comedi: cb_pcidas: fix request_irq() warnTong Zhang
[ Upstream commit 2e5848a3d86f03024ae096478bdb892ab3d79131 ] request_irq() wont accept a name which contains slash so we need to repalce it with something else -- otherwise it will trigger a warning and the entry in /proc/irq/ will not be created since the .name might be used by userspace and we don't want to break userspace, so we are changing the parameters passed to request_irq() [ 1.630764] name 'pci-das1602/16' [ 1.630950] WARNING: CPU: 0 PID: 181 at fs/proc/generic.c:180 __xlate_proc_name+0x93/0xb0 [ 1.634009] RIP: 0010:__xlate_proc_name+0x93/0xb0 [ 1.639441] Call Trace: [ 1.639976] proc_mkdir+0x18/0x20 [ 1.641946] request_threaded_irq+0xfe/0x160 [ 1.642186] cb_pcidas_auto_attach+0xf4/0x610 [cb_pcidas] Suggested-by: Ian Abbott <abbotti@mev.co.uk> Reviewed-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Tong Zhang <ztong0001@gmail.com> Link: https://lore.kernel.org/r/20210315195914.4801-1-ztong0001@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-17staging: comedi: pcl818: Fix endian problem for AI command dataIan Abbott
commit 148e34fd33d53740642db523724226de14ee5281 upstream. The analog input subdevice supports Comedi asynchronous commands that use Comedi's 16-bit sample format. However, the call to `comedi_buf_write_samples()` is passing the address of a 32-bit integer parameter. On bigendian machines, this will copy 2 bytes from the wrong end of the 32-bit value. Fix it by changing the type of the parameter holding the sample value to `unsigned short`. [Note: the bug was introduced in commit edf4537bcbf5 ("staging: comedi: pcl818: use comedi_buf_write_samples()") but the patch applies better to commit d615416de615 ("staging: comedi: pcl818: introduce pcl818_ai_write_sample()").] Fixes: d615416de615 ("staging: comedi: pcl818: introduce pcl818_ai_write_sample()") Cc: <stable@vger.kernel.org> # 4.0+ Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Link: https://lore.kernel.org/r/20210223143055.257402-10-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-17staging: comedi: pcl711: Fix endian problem for AI command dataIan Abbott
commit a084303a645896e834883f2c5170d044410dfdb3 upstream. The analog input subdevice supports Comedi asynchronous commands that use Comedi's 16-bit sample format. However, the call to `comedi_buf_write_samples()` is passing the address of a 32-bit integer variable. On bigendian machines, this will copy 2 bytes from the wrong end of the 32-bit value. Fix it by changing the type of the variable holding the sample value to `unsigned short`. Fixes: 1f44c034de2e ("staging: comedi: pcl711: use comedi_buf_write_samples()") Cc: <stable@vger.kernel.org> # 3.19+ Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Link: https://lore.kernel.org/r/20210223143055.257402-9-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-17staging: comedi: me4000: Fix endian problem for AI command dataIan Abbott
commit b39dfcced399d31e7c4b7341693b18e01c8f655e upstream. The analog input subdevice supports Comedi asynchronous commands that use Comedi's 16-bit sample format. However, the calls to `comedi_buf_write_samples()` are passing the address of a 32-bit integer variable. On bigendian machines, this will copy 2 bytes from the wrong end of the 32-bit value. Fix it by changing the type of the variable holding the sample value to `unsigned short`. Fixes: de88924f67d1 ("staging: comedi: me4000: use comedi_buf_write_samples()") Cc: <stable@vger.kernel.org> # 3.19+ Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Link: https://lore.kernel.org/r/20210223143055.257402-8-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-17staging: comedi: dmm32at: Fix endian problem for AI command dataIan Abbott
commit 54999c0d94b3c26625f896f8e3460bc029821578 upstream. The analog input subdevice supports Comedi asynchronous commands that use Comedi's 16-bit sample format. However, the call to `comedi_buf_write_samples()` is passing the address of a 32-bit integer variable. On bigendian machines, this will copy 2 bytes from the wrong end of the 32-bit value. Fix it by changing the type of the variable holding the sample value to `unsigned short`. [Note: the bug was introduced in commit 1700529b24cc ("staging: comedi: dmm32at: use comedi_buf_write_samples()") but the patch applies better to the later (but in the same kernel release) commit 0c0eadadcbe6e ("staging: comedi: dmm32at: introduce dmm32_ai_get_sample()").] Fixes: 0c0eadadcbe6e ("staging: comedi: dmm32at: introduce dmm32_ai_get_sample()") Cc: <stable@vger.kernel.org> # 3.19+ Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Link: https://lore.kernel.org/r/20210223143055.257402-7-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-17staging: comedi: das800: Fix endian problem for AI command dataIan Abbott
commit 459b1e8c8fe97fcba0bd1b623471713dce2c5eaf upstream. The analog input subdevice supports Comedi asynchronous commands that use Comedi's 16-bit sample format. However, the call to `comedi_buf_write_samples()` is passing the address of a 32-bit integer variable. On bigendian machines, this will copy 2 bytes from the wrong end of the 32-bit value. Fix it by changing the type of the variable holding the sample value to `unsigned short`. Fixes: ad9eb43c93d8 ("staging: comedi: das800: use comedi_buf_write_samples()") Cc: <stable@vger.kernel.org> # 3.19+ Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Link: https://lore.kernel.org/r/20210223143055.257402-6-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-17staging: comedi: das6402: Fix endian problem for AI command dataIan Abbott
commit 1c0f20b78781b9ca50dc3ecfd396d0db5b141890 upstream. The analog input subdevice supports Comedi asynchronous commands that use Comedi's 16-bit sample format. However, the call to `comedi_buf_write_samples()` is passing the address of a 32-bit integer variable. On bigendian machines, this will copy 2 bytes from the wrong end of the 32-bit value. Fix it by changing the type of the variable holding the sample value to `unsigned short`. Fixes: d1d24cb65ee3 ("staging: comedi: das6402: read analog input samples in interrupt handler") Cc: <stable@vger.kernel.org> # 3.19+ Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Link: https://lore.kernel.org/r/20210223143055.257402-5-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-17staging: comedi: adv_pci1710: Fix endian problem for AI command dataIan Abbott
commit b2e78630f733a76508b53ba680528ca39c890e82 upstream. The analog input subdevice supports Comedi asynchronous commands that use Comedi's 16-bit sample format. However, the calls to `comedi_buf_write_samples()` are passing the address of a 32-bit integer variable. On bigendian machines, this will copy 2 bytes from the wrong end of the 32-bit value. Fix it by changing the type of the variables holding the sample value to `unsigned short`. The type of the `val` parameter of `pci1710_ai_read_sample()` is changed to `unsigned short *` accordingly. The type of the `val` variable in `pci1710_ai_insn_read()` is also changed to `unsigned short` since its address is passed to `pci1710_ai_read_sample()`. Fixes: a9c3a015c12f ("staging: comedi: adv_pci1710: use comedi_buf_write_samples()") Cc: <stable@vger.kernel.org> # 4.0+ Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Link: https://lore.kernel.org/r/20210223143055.257402-4-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-17staging: comedi: addi_apci_1500: Fix endian problem for command sampleIan Abbott
commit ac0bbf55ed3be75fde1f8907e91ecd2fd589bde3 upstream. The digital input subdevice supports Comedi asynchronous commands that read interrupt status information. This uses 16-bit Comedi samples (of which only the bottom 8 bits contain status information). However, the interrupt handler is calling `comedi_buf_write_samples()` with the address of a 32-bit variable `unsigned int status`. On a bigendian machine, this will copy 2 bytes from the wrong end of the variable. Fix it by changing the type of the variable to `unsigned short`. Fixes: a8c66b684efa ("staging: comedi: addi_apci_1500: rewrite the subdevice support functions") Cc: <stable@vger.kernel.org> #4.0+ Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Link: https://lore.kernel.org/r/20210223143055.257402-3-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-17staging: comedi: addi_apci_1032: Fix endian problem for COS sampleIan Abbott
commit 25317f428a78fde71b2bf3f24d05850f08a73a52 upstream. The Change-Of-State (COS) subdevice supports Comedi asynchronous commands to read 16-bit change-of-state values. However, the interrupt handler is calling `comedi_buf_write_samples()` with the address of a 32-bit integer `&s->state`. On bigendian architectures, it will copy 2 bytes from the wrong end of the 32-bit integer. Fix it by transferring the value via a 16-bit integer. Fixes: 6bb45f2b0c86 ("staging: comedi: addi_apci_1032: use comedi_buf_write_samples()") Cc: <stable@vger.kernel.org> # 3.19+ Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Link: https://lore.kernel.org/r/20210223143055.257402-2-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-17staging: rtl8192e: Fix possible buffer overflow in _rtl92e_wx_set_scanLee Gibson
commit 8687bf9ef9551bcf93897e33364d121667b1aadf upstream. Function _rtl92e_wx_set_scan calls memcpy without checking the length. A user could control that length and trigger a buffer overflow. Fix by checking the length is within the maximum allowed size. Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Lee Gibson <leegib@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210226145157.424065-1-leegib@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-17staging: rtl8712: Fix possible buffer overflow in r8712_sitesurvey_cmdLee Gibson
commit b93c1e3981af19527beee1c10a2bef67a228c48c upstream. Function r8712_sitesurvey_cmd calls memcpy without checking the length. A user could control that length and trigger a buffer overflow. Fix by checking the length is within the maximum allowed size. Signed-off-by: Lee Gibson <leegib@gmail.com> Link: https://lore.kernel.org/r/20210301132648.420296-1-leegib@gmail.com Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-17staging: ks7010: prevent buffer overflow in ks_wlan_set_scan()Dan Carpenter
commit e163b9823a0b08c3bb8dc4f5b4b5c221c24ec3e5 upstream. The user can specify a "req->essid_len" of up to 255 but if it's over IW_ESSID_MAX_SIZE (32) that can lead to memory corruption. Fixes: 13a9930d15b4 ("staging: ks7010: add driver from Nanonote extra-repository") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/YD4fS8+HmM/Qmrw6@mwanda Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-17staging: rtl8188eu: fix potential memory corruption in rtw_check_beacon_data()Dan Carpenter
commit d4ac640322b06095128a5c45ba4a1e80929fe7f3 upstream. The "ie_len" is a value in the 1-255 range that comes from the user. We have to cap it to ensure that it's not too large or it could lead to memory corruption. Fixes: 9a7fe54ddc3a ("staging: r8188eu: Add source files for new driver - part 1") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/YEHyQCrFZKTXyT7J@mwanda Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-17staging: rtl8712: unterminated string leads to read overflowDan Carpenter
commit d660f4f42ccea50262c6ee90c8e7ad19a69fb225 upstream. The memdup_user() function does not necessarily return a NUL terminated string so this can lead to a read overflow. Switch from memdup_user() to strndup_user() to fix this bug. Fixes: c6dc001f2add ("staging: r8712u: Merging Realtek's latest (v2.6.6). Various fixes.") Cc: stable <stable@vger.kernel.org> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/YDYSR+1rj26NRhvb@mwanda Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-17staging: rtl8188eu: prevent ->ssid overflow in rtw_wx_set_scan()Dan Carpenter
commit 74b6b20df8cfe90ada777d621b54c32e69e27cd7 upstream. This code has a check to prevent read overflow but it needs another check to prevent writing beyond the end of the ->ssid[] array. Fixes: a2c60d42d97c ("staging: r8188eu: Add files for new driver - part 16") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/YEHymwsnHewzoam7@mwanda Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-17staging: rtl8192u: fix ->ssid overflow in r8192_wx_set_scan()Dan Carpenter
commit 87107518d7a93fec6cdb2559588862afeee800fb upstream. We need to cap len at IW_ESSID_MAX_SIZE (32) to avoid memory corruption. This can be controlled by the user via the ioctl. Fixes: 5f53d8ca3d5d ("Staging: add rtl8192SU wireless usb driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/YEHoAWMOSZBUw91F@mwanda Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-07staging: most: sound: add sanity check for function argumentChristian Gromm
[ Upstream commit 45b754ae5b82949dca2b6e74fa680313cefdc813 ] This patch checks the function parameter 'bytes' before doing the subtraction to prevent memory corruption. Signed-off-by: Christian Gromm <christian.gromm@microchip.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/1612282865-21846-1-git-send-email-christian.gromm@microchip.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-07staging: fwserial: Fix error handling in fwserial_createDinghao Liu
[ Upstream commit f31559af97a0eabd467e4719253675b7dccb8a46 ] When fw_core_add_address_handler() fails, we need to destroy the port by tty_port_destroy(). Also we need to unregister the address handler by fw_core_remove_address_handler() on failure. Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Link: https://lore.kernel.org/r/20201221122437.10274-1-dinghao.liu@zju.edu.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04staging: rtl8188eu: Add Edimax EW-7811UN V2 to device tableMartin Kaiser
commit 7a8d2f1908a59003e55ef8691d09efb7fbc51625 upstream. The Edimax EW-7811UN V2 uses an RTL8188EU chipset and works with this driver. Signed-off-by: Martin Kaiser <martin@kaiser.cx> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210204085217.9743-1-martin@kaiser.cx Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-04staging: gdm724x: Fix DMA from stackAmey Narkhede
commit 7c3a0635cd008eaca9a734dc802709ee0b81cac5 upstream. Stack allocated buffers cannot be used for DMA on all architectures so allocate hci_packet buffer using kmalloc. Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Link: https://lore.kernel.org/r/20210211053819.34858-1-ameynarkhede03@gmail.com Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-04staging/mt7621-dma: mtk-hsdma.c->hsdma-mt7621.cIlya Lipnitskiy
commit 1f92798cbe7fe923479cff754dd06dd23d352e36 upstream. Also use KBUILD_MODNAME for module name. This driver is only used by RALINK MIPS MT7621 SoCs. Tested by building against that target using OpenWrt with Linux 5.10.10. Fixes the following error: error: the following would cause module name conflict: drivers/dma/mediatek/mtk-hsdma.ko drivers/staging/mt7621-dma/mtk-hsdma.ko Cc: stable@vger.kernel.org Cc: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com> Link: https://lore.kernel.org/r/20210130034507.2115280-1-ilya.lipnitskiy@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-04staging: rtl8723bs: wifi_regd.c: Fix incorrect number of regulatory rulesChen-Yu Tsai
[ Upstream commit 61834c967a929f6b4b7fcb91f43fa225cc29aa19 ] The custom regulatory ruleset in the rtl8723bs driver lists an incorrect number of rules: one too many. This results in an out-of-bounds access, as detected by KASAN. This was possible thanks to the newly added support for KASAN on ARMv7. Fix this by filling in the correct number of rules given. KASAN report: ================================================================== BUG: KASAN: global-out-of-bounds in cfg80211_does_bw_fit_range+0x14/0x4c [cfg80211] Read of size 4 at addr bf20c254 by task ip/971 CPU: 2 PID: 971 Comm: ip Tainted: G C 5.11.0-rc2-00020-gf7fe528a7ebe #1 Hardware name: Allwinner sun8i Family [<c0113338>] (unwind_backtrace) from [<c010e8a4>] (show_stack+0x10/0x14) [<c010e8a4>] (show_stack) from [<c0e0f868>] (dump_stack+0x9c/0xb4) [<c0e0f868>] (dump_stack) from [<c0388284>] (print_address_description.constprop.2+0x1dc/0x2dc) [<c0388284>] (print_address_description.constprop.2) from [<c03885cc>] (kasan_report+0x1a8/0x1c4) [<c03885cc>] (kasan_report) from [<bf00a354>] (cfg80211_does_bw_fit_range+0x14/0x4c [cfg80211]) [<bf00a354>] (cfg80211_does_bw_fit_range [cfg80211]) from [<bf00b41c>] (freq_reg_info_regd.part.6+0x108/0x124 [> [<bf00b41c>] (freq_reg_info_regd.part.6 [cfg80211]) from [<bf00df00>] (handle_channel_custom.constprop.12+0x48/> [<bf00df00>] (handle_channel_custom.constprop.12 [cfg80211]) from [<bf00e150>] (wiphy_apply_custom_regulatory+0> [<bf00e150>] (wiphy_apply_custom_regulatory [cfg80211]) from [<bf1fb9e8>] (rtw_regd_init+0x60/0x70 [r8723bs]) [<bf1fb9e8>] (rtw_regd_init [r8723bs]) from [<bf1ee5a8>] (rtw_cfg80211_init_wiphy+0x164/0x1e8 [r8723bs]) [<bf1ee5a8>] (rtw_cfg80211_init_wiphy [r8723bs]) from [<bf1f8d50>] (_netdev_open+0xe4/0x28c [r8723bs]) [<bf1f8d50>] (_netdev_open [r8723bs]) from [<bf1f8f58>] (netdev_open+0x60/0x88 [r8723bs]) [<bf1f8f58>] (netdev_open [r8723bs]) from [<c0bb3730>] (__dev_open+0x178/0x220) [<c0bb3730>] (__dev_open) from [<c0bb3cdc>] (__dev_change_flags+0x258/0x2c4) [<c0bb3cdc>] (__dev_change_flags) from [<c0bb3d88>] (dev_change_flags+0x40/0x80) [<c0bb3d88>] (dev_change_flags) from [<c0bc86fc>] (do_setlink+0x538/0x1160) [<c0bc86fc>] (do_setlink) from [<c0bcf9e8>] (__rtnl_newlink+0x65c/0xad8) [<c0bcf9e8>] (__rtnl_newlink) from [<c0bcfeb0>] (rtnl_newlink+0x4c/0x6c) [<c0bcfeb0>] (rtnl_newlink) from [<c0bc67c8>] (rtnetlink_rcv_msg+0x1f8/0x454) [<c0bc67c8>] (rtnetlink_rcv_msg) from [<c0c330e4>] (netlink_rcv_skb+0xc4/0x1e0) [<c0c330e4>] (netlink_rcv_skb) from [<c0c32478>] (netlink_unicast+0x2c8/0x3c4) [<c0c32478>] (netlink_unicast) from [<c0c32894>] (netlink_sendmsg+0x320/0x5f0) [<c0c32894>] (netlink_sendmsg) from [<c0b75eb0>] (____sys_sendmsg+0x320/0x3e0) [<c0b75eb0>] (____sys_sendmsg) from [<c0b78394>] (___sys_sendmsg+0xe8/0x12c) [<c0b78394>] (___sys_sendmsg) from [<c0b78a50>] (__sys_sendmsg+0xc0/0x120) [<c0b78a50>] (__sys_sendmsg) from [<c0100060>] (ret_fast_syscall+0x0/0x58) Exception stack(0xc5693fa8 to 0xc5693ff0) 3fa0: 00000074 c7a39800 00000003 b6cee648 00000000 00000000 3fc0: 00000074 c7a39800 00000001 00000128 78d18349 00000000 b6ceeda0 004f7cb0 3fe0: 00000128 b6cee5e8 aeca151f aec1d746 The buggy address belongs to the variable: rtw_drv_halt+0xf908/0x6b4 [r8723bs] Memory state around the buggy address: bf20c100: 00 00 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 bf20c180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >bf20c200: 00 00 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 ^ bf20c280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 bf20c300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Signed-off-by: Chen-Yu Tsai <wens@csie.org> Link: https://lore.kernel.org/r/20210108141401.31741-1-wens@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-01-12staging: mt7621-dma: Fix a resource leak in an error handling pathChristophe JAILLET
commit d887d6104adeb94d1b926936ea21f07367f0ff9f upstream. If an error occurs after calling 'mtk_hsdma_init()', it must be undone by a corresponding call to 'mtk_hsdma_uninit()' as already done in the remove function. Fixes: 0853c7a53eb3 ("staging: mt7621-dma: ralink: add rt2880 dma engine") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201213153513.138723-1-christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30spi: mt7621: fix missing clk_disable_unprepare() on error in mt7621_spi_probeQinglang Miao
commit 702b15cb97123cedcec56a39d9a21c5288eb9ae1 upstream. Fix the missing clk_disable_unprepare() before return from mt7621_spi_probe in the error handling case. Fixes: cbd66c626e16 ("spi: mt7621: Move SPI driver out of staging") Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com> Link: https://lore.kernel.org/r/20201103074912.195576-1-miaoqinglang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30staging: comedi: mf6x4: Fix AI end-of-conversion detectionIan Abbott
commit 56c90457ebfe9422496aac6ef3d3f0f0ea8b2ec2 upstream. I have had reports from two different people that attempts to read the analog input channels of the MF624 board fail with an `ETIMEDOUT` error. After triggering the conversion, the code calls `comedi_timeout()` with `mf6x4_ai_eoc()` as the callback function to check if the conversion is complete. The callback returns 0 if complete or `-EBUSY` if not yet complete. `comedi_timeout()` returns `-ETIMEDOUT` if it has not completed within a timeout period which is propagated as an error to the user application. The existing code considers the conversion to be complete when the EOLC bit is high. However, according to the user manuals for the MF624 and MF634 boards, this test is incorrect because EOLC is an active low signal that goes high when the conversion is triggered, and goes low when the conversion is complete. Fix the problem by inverting the test of the EOLC bit state. Fixes: 04b565021a83 ("comedi: Humusoft MF634 and MF624 DAQ cards driver") Cc: <stable@vger.kernel.org> # v4.4+ Cc: Rostislav Lisovy <lisovy@gmail.com> Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Link: https://lore.kernel.org/r/20201207145806.4046-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30speakup: fix uninitialized flush_lockYang Yingliang
[ Upstream commit d1b928ee1cfa965a3327bbaa59bfa005d97fa0fe ] The flush_lock is uninitialized, use DEFINE_SPINLOCK to define and initialize flush_lock. Fixes: c6e3fd22cd53 ("Staging: add speakup to the staging directory") Reported-by: Hulk Robot <hulkci@huawei.com> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20201117012229.3395186-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30staging: gasket: interrupt: fix the missed eventfd_ctx_put() in ↵Jing Xiangfeng
gasket_interrupt.c [ Upstream commit ab5b769a23af12a675b9f3d7dd529250c527f5ac ] gasket_interrupt_set_eventfd() misses to call eventfd_ctx_put() in an error path. We check interrupt is valid before calling eventfd_ctx_fdget() to fix it. There is the same issue in gasket_interrupt_clear_eventfd(), Add the missed function call to fix it. Fixes: 9a69f5087ccc ("drivers/staging: Gasket driver framework + Apex driver") Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com> Link: https://lore.kernel.org/r/20201112064924.99680-1-jingxiangfeng@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30staging: greybus: codecs: Fix reference counter leak in error handlingZhang Qilong
[ Upstream commit 3952659a6108f77a0d062d8e8487bdbdaf52a66c ] gb_pm_runtime_get_sync has increased the usage counter of the device here. Forgetting to call gb_pm_runtime_put_noidle will result in usage counter leak in the error branch of (gbcodec_hw_params and gbcodec_prepare). We fixed it by adding it. Fixes: c388ae7696992 ("greybus: audio: Update pm runtime support in dai_ops callback") Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Link: https://lore.kernel.org/r/20201109131347.1725288-2-zhangqilong3@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-11speakup: Reject setting the speakup line discipline outside of speakupSamuel Thibault
commit f0992098cadb4c9c6a00703b66cafe604e178fea upstream. Speakup exposing a line discipline allows userland to try to use it, while it is deemed to be useless, and thus uselessly exposes potential bugs. One of them is simply that in such a case if the line sends data, spk_ttyio_receive_buf2 is called and crashes since spk_ttyio_synth is NULL. This change restricts the use of the speakup line discipline to speakup drivers, thus avoiding such kind of issues altogether. Cc: stable@vger.kernel.org Reported-by: Shisong Qin <qinshisong1205@gmail.com> Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Tested-by: Shisong Qin <qinshisong1205@gmail.com> Link: https://lore.kernel.org/r/20201129193523.hm3f6n5xrn6fiyyc@function Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-24staging: rtl8723bs: Add 024c:0627 to the list of SDIO device-idsBrian O'Keefe
commit aee9dccc5b64e878cf1b18207436e73f66d74157 upstream. Add 024c:0627 to the list of SDIO device-ids, based on hardware found in the wild. This hardware exists on at least some Acer SW1-011 tablets. Signed-off-by: Brian O'Keefe <bokeefe@alum.wpi.edu> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/b9e1523f-2ba7-fb82-646a-37f095b4440e@alum.wpi.edu Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-24speakup: Do not let the line discipline be used several timesSamuel Thibault
commit d4122754442799187d5d537a9c039a49a67e57f1 upstream. Speakup has only one speakup_tty variable to store the tty it is managing. This makes sense since its codebase currently assumes that there is only one user who controls the screen reading. That however means that we have to forbid using the line discipline several times, otherwise the second closure would try to free a NULL ldisc_data, leading to general protection fault: 0000 [#1] SMP KASAN PTI RIP: 0010:spk_ttyio_ldisc_close+0x2c/0x60 Call Trace: tty_ldisc_release+0xa2/0x340 tty_release_struct+0x17/0xd0 tty_release+0x9d9/0xcc0 __fput+0x231/0x740 task_work_run+0x12c/0x1a0 do_exit+0x9b5/0x2230 ? release_task+0x1240/0x1240 ? __do_page_fault+0x562/0xa30 do_group_exit+0xd5/0x2a0 __x64_sys_exit_group+0x35/0x40 do_syscall_64+0x89/0x2b0 ? page_fault+0x8/0x30 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Cc: stable@vger.kernel.org Reported-by: 秦世松 <qinshisong1205@gmail.com> Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Tested-by: Shisong Qin <qinshisong1205@gmail.com> Link: https://lore.kernel.org/r/20201110183541.fzgnlwhjpgqzjeth@function Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-18erofs: derive atime instead of leaving it emptyGao Xiang
commit d3938ee23e97bfcac2e0eb6b356875da73d700df upstream. EROFS has _only one_ ondisk timestamp (ctime is currently documented and recorded, we might also record mtime instead with a new compat feature if needed) for each extended inode since EROFS isn't mainly for archival purposes so no need to keep all timestamps on disk especially for Android scenarios due to security concerns. Also, romfs/cramfs don't have their own on-disk timestamp, and squashfs only records mtime instead. Let's also derive access time from ondisk timestamp rather than leaving it empty, and if mtime/atime for each file are really needed for specific scenarios as well, we can also use xattrs to record them then. Link: https://lore.kernel.org/r/20201031195102.21221-1-hsiangkao@aol.com [ Gao Xiang: It'd be better to backport for user-friendly concern. ] Fixes: 431339ba9042 ("staging: erofs: add inode operations") Cc: stable <stable@vger.kernel.org> # 4.19+ Reported-by: nl6720 <nl6720@gmail.com> Reviewed-by: Chao Yu <yuchao0@huawei.com> [ Gao Xiang: Manually backport to 4.19.y due to trivial conflicts. ] Signed-off-by: Gao Xiang <hsiangkao@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-05staging: octeon: Drop on uncorrectable alignment or FCS errorAlexander Sverdlin
commit 49d28ebdf1e30d806410eefc7de0a7a1ca5d747c upstream. Currently in case of alignment or FCS error if the packet cannot be corrected it's still not dropped. Report the error properly and drop the packet while making the code around a little bit more readable. Fixes: 80ff0fd3ab64 ("Staging: Add octeon-ethernet driver files.") Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201016145630.41852-1-alexander.sverdlin@nokia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-05staging: octeon: repair "fixed-link" supportAlexander Sverdlin
commit 179f5dc36b0a1aa31538d7d8823deb65c39847b3 upstream. The PHYs must be registered once in device probe function, not in device open callback because it's only possible to register them once. Fixes: a25e278020bf ("staging: octeon: support fixed-link phys") Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201016101858.11374-1-alexander.sverdlin@nokia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-05staging: comedi: cb_pcidas: Allow 2-channel commands for AO subdeviceIan Abbott
commit 647a6002cb41d358d9ac5de101a8a6dc74748a59 upstream. The "cb_pcidas" driver supports asynchronous commands on the analog output (AO) subdevice for those boards that have an AO FIFO. The code (in `cb_pcidas_ao_check_chanlist()` and `cb_pcidas_ao_cmd()`) to validate and set up the command supports output to a single channel or to two channels simultaneously (the boards have two AO channels). However, the code in `cb_pcidas_auto_attach()` that initializes the subdevices neglects to initialize the AO subdevice's `len_chanlist` member, leaving it set to 0, but the Comedi core will "correct" it to 1 if the driver neglected to set it. This limits commands to use a single channel (either channel 0 or 1), but the limit should be two channels. Set the AO subdevice's `len_chanlist` member to be the same value as the `n_chan` member, which will be 2. Cc: <stable@vger.kernel.org> Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Link: https://lore.kernel.org/r/20201021122142.81628-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-29staging: rtl8192u: Do not use GFP_KERNEL in atomic contextChristophe JAILLET
[ Upstream commit acac75bb451fd39344eb54fad6602dfc9482e970 ] 'rtl8192_irq_rx_tasklet()' is a tasklet initialized in 'rtl8192_init_priv_task()'. >From this function it is possible to allocate some memory with the GFP_KERNEL flag, which is not allowed in the atomic context of a tasklet. Use GFP_ATOMIC instead. The call chain is: rtl8192_irq_rx_tasklet (in r8192U_core.c) --> rtl8192_rx_nomal (in r8192U_core.c) --> ieee80211_rx (in ieee80211/ieee80211_rx.c) --> RxReorderIndicatePacket (in ieee80211/ieee80211_rx.c) Fixes: 79a5ccd97209 ("staging: rtl8192u: fix large frame size compiler warning") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/20200813173458.758284-1-christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>