- 23 Jan, 2020 40 commits
-
-
Varun Prakash authored
[ Upstream commit 71482fde ] If cxgb4i_ddp_init() fails then cdev->cdev2ppm will be NULL, so add a check for NULL pointer before dereferencing it. Link: https://lore.kernel.org/r/1576676731-3068-1-git-send-email-varun@chelsio.comSigned-off-by:
Varun Prakash <varun@chelsio.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Johnson CH Chen (陳昭勳) authored
[ Upstream commit 322f6a31 ] Dear Linus Walleij, In old kernels, some APIs still try to use parent->of_node from struct gpio_chip, and it could be resulted in kernel panic because parent is NULL. Adding platform device to gpiochip->parent can fix this problem. Signed-off-by:
Johnson Chen <johnsonch.chen@moxa.com> Link: https://patchwork.kernel.org/patch/11234609 Link: https://lore.kernel.org/r/HK0PR01MB3521489269F76467DFD7843FFA450@HK0PR01MB3521.apcprd01.prod.exchangelabs.comSigned-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Kars de Jong authored
commit e34494c8 upstream. The driver was reading the wrong register as the 10-hour digit due to a misplaced ')'. It was in fact reading the 1-second digit register due to this bug. Also remove the use of a magic number for the hour mask and use the define for it which was already present. Fixes: 4f9b9bba ("rtc: Add an RTC driver for the Oki MSM6242") Tested-by:
Kars de Jong <jongk@linux-m68k.org> Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Chao Yu authored
commit 1f0d5c91 upstream. We expect 64-bit calculation result from below statement, however in 32-bit machine, looped left shift operation on pgoff_t type variable may cause overflow issue, fix it by forcing type cast. page->index << PAGE_SHIFT; Fixes: 26de9b11 ("f2fs: avoid unnecessary updating inode during fsync") Fixes: 0a2aa8fb ("f2fs: refactor __exchange_data_block for speed up") Signed-off-by:
Chao Yu <yuchao0@huawei.com> Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by:
-
Nathan Chancellor authored
commit 091c6e9c upstream. When building with Clang + -Wtautological-pointer-compare: drivers/net/wireless/realtek/rtlwifi/regd.c:389:33: warning: comparison of address of 'rtlpriv->regd' equal to a null pointer is always false [-Wtautological-pointer-compare] if (wiphy == NULL || &rtlpriv->regd == NULL) ~~~~~~~~~^~~~ ~~~~ 1 warning generated. The address of an array member is never NULL unless it is the first struct member so remove the unnecessary check. This was addressed in the staging version of the driver in commit f986978b ("Staging: rtlwifi: remove unnecessary NULL check"). While we are here, fix the following checkpatch warning: CHECK: Comparison to NULL could be written "!wiphy" 35: FILE: drivers/net/wireless/realtek/rtlwifi/regd.c:389: + if (wiphy == NULL) Fixes: 0c817338 ("rtl8192ce: Add new driver") Link:https://github.com/ClangBuiltLinux/linux/issues/750Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Acked-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Mans Rullgard authored
commit fed8d8c7 upstream. The driver does the wrong thing when cs_change is set on a non-last xfer in a message. When cs_change is set, the driver deactivates the CS and leaves it off until a later xfer again has cs_change set whereas it should be briefly toggling CS off and on again. This patch brings the behaviour of the driver back in line with the documentation and common sense. The delay of 10 us is the same as is used by the default spi_transfer_one_message() function in spi.c. [gregory: rebased on for-5.5 from spi tree] Fixes: 8090d6d1 ("spi: atmel: Refactor spi-atmel to use SPI framework queue") Signed-off-by:
Mans Rullgard <mans@mansr.com> Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
Gregory CLEMENT <gregory.clement@bootlin.com> Link: https://lore.kernel.org/r/20191018153504.4249-1-gregory.clement@bootlin.comSigned-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Sergei Shtylyov authored
commit a719a75a upstream. spi_nor_read() assigns the result of 'ssize_t spi_nor_read_data()' to the 'int ret' variable, while 'ssize_t' is a 64-bit type and *int* is a 32-bit type on the 64-bit machines. This silent truncation isn't really valid, so fix up the variable's type. Fixes: 59451e12 ("mtd: spi-nor: change return value of read/write") Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by:
-
Seung-Woo Kim authored
commit 704c6c80 upstream. >From isp_video_release(), &isp->video_lock is held and subsequent vb2_fop_release() tries to lock vdev->lock which is same with the previous one. Replace vb2_fop_release() with _vb2_fop_release() to fix the recursive locking. Fixes: 1380f575 ("[media] videobuf2: Add missing lock held on vb2_fop_release") Signed-off-by:
Seung-Woo Kim <sw0312.kim@samsung.com> Reviewed-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by:
-
Peng Fan authored
commit 74887542 upstream. Per Documentation/DMA-API-HOWTO.txt, To unmap a scatterlist, just call: dma_unmap_sg(dev, sglist, nents, direction); .. note:: The 'nents' argument to the dma_unmap_sg call must be the _same_ one you passed into the dma_map_sg call, it should _NOT_ be the 'count' value _returned_ from the dma_map_sg call. However in the driver, priv->nent is directly assigned with value returned from dma_map_sg, and dma_unmap_sg use priv->nent for unmap, this breaks the API usage. So introduce a new entry orig_nent to remember 'nents'. Fixes: da3564ee ("pch_uart: add multi-scatter processing") Signed-off-by:
Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/1573623259-6339-1-git-send-email-peng.fan@nxp.comSigned-off-by:
-
Peng Fan authored
commit 596fd8df upstream. The dmaengine_prep_slave_sg needs to use sg count returned by dma_map_sg, not use sport->dma_tx_nents, because the return value of dma_map_sg is not always same with "nents". Fixes: b4cdc8f6 ("serial: imx: add DMA support for imx6q") Signed-off-by:
-
Oliver O'Halloran authored
commit 9d72dcef upstream. On PowerNV the PCIe topology is (currently) managed by the powernv platform code in Linux in cooperation with the platform firmware. Linux's native PCIe port service drivers operate independently of both and this can cause problems. The main issue is that the portbus driver will conflict with the platform specific hotplug driver (pnv_php) over ownership of the MSI used to notify the host when a hotplug event occurs. The portbus driver claims this MSI on behalf of the individual port services because the same interrupt is used for hotplug events, PMEs (on root ports), and link bandwidth change notifications. The portbus driver will always claim the interrupt even if the individual port service drivers, such as pciehp, are compiled out. The second, bigger, problem is that the hotplug port service driver fundamentally does not work on PowerNV. The platform assumes that all PCI devices have a corresponding arch-specific handle derived from the DT node for the device (pci_dn) and without one the platform will not allow a PCI device to be enabled. This problem is largely due to historical baggage, but it can't be resolved without significant re-factoring of the platform PCI support. We can fix these problems in the interim by setting the "pcie_ports_disabled" flag during platform initialisation. The flag indicates the platform owns the PCIe ports which stops the portbus driver from being registered. This does have the side effect of disabling all port services drivers that is: AER, PME, BW notifications, hotplug, and DPC. However, this is not a huge disadvantage on PowerNV since these services are either unused or handled through other means. Fixes: 66725152 ("PCI/hotplug: PowerPC PowerNV PCI hotplug driver") Signed-off-by:
Oliver O'Halloran <oohall@gmail.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20191118065553.30362-1-oohall@gmail.comSigned-off-by:
-
Bjorn Helgaas authored
commit 127a7709 upstream. The granularity message has an extra "d": pci 0000:02:00.0: PTM enabled, 4dns granularity Remove the "d" so the message is simply "PTM enabled, 4ns granularity". Fixes: 8b2ec318 ("PCI: Add PTM clock granularity information") Link: https://lore.kernel.org/r/20191106222420.10216-2-helgaas@kernel.orgSigned-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Andrew Murray <andrew.murray@arm.com> Cc: Jonathan Yong <jonathan.yong@intel.com> Signed-off-by:
-
Arnd Bergmann authored
commit 9d7bf41f upstream. Unlike the normal SIOCOUTQ, SIOCOUTQNSD was never handled in compat mode. Add it to the common socket compat handler along with similar ones. Fixes: 2f4e1b39 ("tcp: ioctl type SIOCOUTQNSD returns amount of data not sent") Cc: Eric Dumazet <edumazet@google.com> Cc: netdev@vger.kernel.org Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Marian Mihailescu authored
commit e21be0d1 upstream. Save and restore top PLL related configuration registers for big (APLL) and LITTLE (KPLL) cores during suspend/resume cycle. So far, CPU clocks were reset to default values after suspend/resume cycle and performance after system resume was affected when performance governor has been selected. Fixes: 77342432 ("clk: samsung: exynos5420: add more registers to restore list") Signed-off-by:
Marian Mihailescu <mihailescu2m@gmail.com> Signed-off-by:
-
Alexander Usyskin authored
commit 73668309 upstream. mei client bus added the client protocol version to the device alias, but ABI documentation was not updated. Fixes: b26864ca (mei: bus: add client protocol version to the device alias) Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Link: https://lore.kernel.org/r/20191008005735.12707-1-tomas.winkler@intel.comSigned-off-by:
-
Alexandru Ardelean authored
commit 9b742763 upstream. This was found only after the whole thing with the inline functions, but the compiler actually found something. The value of the `bias` (in adis16480_get_calibbias()) should only be set if the read operation was successful. No actual known problem occurs as users of this function all ultimately check the return value. Hence probably not stable material. Fixes: 2f3abe6c ("iio:imu: Add support for the ADIS16480 and similar IMUs") Signed-off-by:
Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Jian-Hong Pan authored
commit 176a7fca upstream. Some of ASUS laptops like UX431FL keyboard backlight cannot be set to brightness 0. According to ASUS' information, the brightness should be 0x80 ~ 0x83. This patch fixes it by following the logic. Fixes: e9809c0b ("asus-wmi: add keyboard backlight support") Signed-off-by:
Jian-Hong Pan <jian-hong@endlessm.com> Reviewed-by:
Daniel Drake <drake@endlessm.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Xiang Chen authored
commit 465f4eda upstream. If an attached disk with protection information enabled is reformatted to Type 0 the revalidation code does not clear the original protection type and subsequent accesses will keep setting RDPROTECT/WRPROTECT. Set the protection type to 0 if the disk reports PROT_EN=0 in READ CAPACITY(16). [mkp: commit desc] Fixes: fe542396 ("[SCSI] sd: Ensure we correctly disable devices with unknown protection type") Link: https://lore.kernel.org/r/1578532344-101668-1-git-send-email-chenxiang66@hisilicon.comSigned-off-by:
Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by:
-
James Bottomley authored
commit 529244bd upstream. Doing an add/remove/add on a SCSI device in an enclosure leads to an oops caused by poisoned values in the enclosure device list pointers. The reason is because we are keeping the enclosure device across the enclosed device add/remove/add but the current code is doing a device_add/device_del/device_add on it. This is the wrong thing to do in sysfs, so fix it by not doing a device_del on the enclosure device simply because of a hot remove of the drive in the slot. [mkp: added missing email addresses] Fixes: 43d8eb9c ("[SCSI] ses: add support for enclosure component hot removal") Link: https://lore.kernel.org/r/1578532892.3852.10.camel@HansenPartnership.comSigned-off-by:
James Bottomley <James.Bottomley@HansenPartnership.com> Reported-by:
Luo Jiaxing <luojiaxing@huawei.com> Tested-by:
John Garry <john.garry@huawei.com> Signed-off-by:
-
Bart Van Assche authored
commit e88982ad upstream. The code added by this patch is similar to the code that already exists in ibmvscsis_determine_resid(). This patch has been tested by running the following command: strace sg_raw -r 1k /dev/sdb 12 00 00 00 60 00 -o inquiry.bin |& grep resid= Link: https://lore.kernel.org/r/20191105214632.183302-1-bvanassche@acm.org Fixes: a42d985b ("ib_srpt: Initial SRP Target merge for v3.3-rc1") Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Acked-by:
Honggang Li <honli@redhat.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Nathan Chancellor authored
commit 7935799e upstream. Clang warns: ../fs/cifs/smb2file.c:70:3: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation] if (oparms->tcon->use_resilient) { ^ ../fs/cifs/smb2file.c:66:2: note: previous statement is here if (rc) ^ 1 warning generated. This warning occurs because there is a space after the tab on this line. Remove it so that the indentation is consistent with the Linux kernel coding style and clang no longer warns. Fixes: 592fafe6 ("Add resilienthandles mount parm") Link: https://github.com/ClangBuiltLinux/linux/issues/826Signed-off-by:
Steve French <stfrench@microsoft.com> Signed-off-by:
-
Taehee Yoo authored
commit 3ed0a1d5 upstream. The supervision frame is L2 frame. When supervision frame is created, hsr module doesn't set network header. If tap routine is enabled, dev_queue_xmit_nit() is called and it checks network_header. If network_header pointer wasn't set(or invalid), it resets network_header and warns. In order to avoid unnecessary warning message, resetting network_header is needed. Test commands: ip netns add nst ip link add veth0 type veth peer name veth1 ip link add veth2 type veth peer name veth3 ip link set veth1 netns nst ip link set veth3 netns nst ip link set veth0 up ip link set veth2 up ip link add hsr0 type hsr slave1 veth0 slave2 veth2 ip a a 192.168.100.1/24 dev hsr0 ip link set hsr0 up ip netns exec nst ip link set veth1 up ip netns exec nst ip link set veth3 up ip netns exec nst ip link add hsr1 type hsr slave1 veth1 slave2 veth3 ip netns exec nst ip a a 192.168.100.2/24 dev hsr1 ip netns exec nst ip link set hsr1 up tcpdump -nei veth0 Splat looks like: [ 175.852292][ C3] protocol 88fb is buggy, dev veth0 Fixes: f421436a ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)") Signed-off-by:
Taehee Yoo <ap420073@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Geert Uytterhoeven authored
commit d935bd50 upstream. When a GPIO offset in a lookup table is out-of-range, the printed error message (1) does not include the actual out-of-range value, and (2) contains an off-by-one error in the upper bound. Avoid user confusion by also printing the actual GPIO offset, and correcting the upper bound of the range. While at it, use "%u" for unsigned int. Sample impact: -requested GPIO 0 is out of range [0..32] for chip e6052000.gpio +requested GPIO 0 (45) is out of range [0..31] for chip e6052000.gpio Fixes: 2a3cf6a3 ("gpiolib: return -ENOENT if no GPIO mapping exists") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20191127095919.4214-1-geert+renesas@glider.beSigned-off-by:
-
Jon Derrick authored
commit 7d4e6ccd upstream. This adds the missing teardown step that removes the device link from the group when the device addition fails. Signed-off-by:
Jon Derrick <jonathan.derrick@intel.com> Fixes: 797a8b4d ("iommu: Handle default domain attach failure") Reviewed-by:
Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Ran Bi authored
commit 653997ee upstream. Alarm registers high byte was reserved for other functions. This add mask in alarm registers operation functions. This also fix error condition in interrupt handler. Fixes: fc297911 ("rtc: mediatek: Add MT6397 RTC driver") Signed-off-by:
Ran Bi <ran.bi@mediatek.com> Signed-off-by:
Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com> Link: https://lore.kernel.org/r/1576057435-3561-6-git-send-email-hsin-hsiung.wang@mediatek.comSigned-off-by:
-
YueHaibing authored
commit 1d3ff095 upstream. If dccp_feat_push_change fails, we forget free the mem which is alloced by kmemdup in dccp_feat_clone_sp_val. Reported-by:
Hulk Robot <hulkci@huawei.com> Fixes: e8ef967a ("dccp: Registration routines for changing feature values") Reviewed-by:
Mukesh Ojha <mojha@codeaurora.org> Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by:
-
Theodore Ts'o authored
commit 4ea99936 upstream. It's possible to specify a non-zero s_want_extra_isize via debugging option, and this can cause bad things(tm) to happen when using a file system with an inode size of 128 bytes. Add better checking when the file system is mounted, as well as when we are actually doing the trying to do the inode expansion. Link: https://lore.kernel.org/r/20191110121510.GH23325@mit.edu Reported-by: syzbot+f8d6f8386ceacdbfff57@syzkaller.appspotmail.com Reported-by: syzbot+33d7ea72e47de3bdf4e1@syzkaller.appspotmail.com Reported-by: syzbot+44b6763edfc17144296f@syzkaller.appspotmail.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu> [bwh: Backported to 4.9: adjust context] Signed-off-by:
-
Barret Rhoden authored
commit 7bc04c5c upstream. When remounting with debug_want_extra_isize, we were not performing the same checks that we do during a normal mount. That allowed us to set a value for s_want_extra_isize that reached outside the s_inode_size. Fixes: e2b911c5 ("ext4: clean up feature test macros with predicate functions") Reported-by: syzbot+f584efa0ac7213c226b7@syzkaller.appspotmail.com Reviewed-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Barret Rhoden <brho@google.com> Signed-off-by:
-
Navid Emamdoost authored
commit 6f3ef5c2 upstream. In the implementation of i2400m_op_rfkill_sw_toggle() the allocated buffer for cmd should be released before returning. The documentation for i2400m_msg_to_dev() says when it returns the buffer can be reused. Meaning cmd should be released in either case. Move kfree(cmd) before return to be reached by all execution paths. Fixes: 2507e6ab ("wimax: i2400: fix memory leak") Signed-off-by:
Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by:
-
Navid Emamdoost authored
commit 2507e6ab upstream. In i2400m_op_rfkill_sw_toggle cmd buffer should be released along with skb response. Signed-off-by:
-
Vandana BN authored
commit 5d2e73a5 upstream. SyzKaller hit the null pointer deref while reading from uninitialized udev->product in zr364xx_vidioc_querycap(). ================================================================== BUG: KASAN: null-ptr-deref in read_word_at_a_time+0xe/0x20 include/linux/compiler.h:274 Read of size 1 at addr 0000000000000000 by task v4l_id/5287 CPU: 1 PID: 5287 Comm: v4l_id Not tainted 5.1.0-rc3-319004-g43151d6 #6 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xe8/0x16e lib/dump_stack.c:113 kasan_report.cold+0x5/0x3c mm/kasan/report.c:321 read_word_at_a_time+0xe/0x20 include/linux/compiler.h:274 strscpy+0x8a/0x280 lib/string.c:207 zr364xx_vidioc_querycap+0xb5/0x210 drivers/media/usb/zr364xx/zr364xx.c:706 v4l_querycap+0x12b/0x340 drivers/media/v4l2-core/v4l2-ioctl.c:1062 __video_do_ioctl+0x5bb/0xb40 drivers/media/v4l2-core/v4l2-ioctl.c:2874 video_usercopy+0x44e/0xf00 drivers/media/v4l2-core/v4l2-ioctl.c:3056 v4l2_ioctl+0x14e/0x1a0 drivers/media/v4l2-core/v4l2-dev.c:364 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0xced/0x12f0 fs/ioctl.c:696 ksys_ioctl+0xa0/0xc0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x74/0xb0 fs/ioctl.c:718 do_syscall_64+0xcf/0x4f0 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f3b56d8b347 Code: 90 90 90 48 8b 05 f1 fa 2a 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 90 90 90 90 90 90 90 90 90 90 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c1 fa 2a 00 31 d2 48 29 c2 64 RSP: 002b:00007ffe005d5d68 EFLAGS: 00000202 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f3b56d8b347 RDX: 00007ffe005d5d70 RSI: 0000000080685600 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000400884 R13: 00007ffe005d5ec0 R14: 0000000000000000 R15: 0000000000000000 ================================================================== For this device udev->product is not initialized and accessing it causes a NULL pointer deref. The fix is to check for NULL before strscpy() and copy empty string, if product is NULL Reported-by: syzbot+66010012fd4c531a1a96@syzkaller.appspotmail.com Signed-off-by:
Vandana BN <bnvandana@gmail.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> [bwh: Backported to 4.9: This function uses strlcpy() instead of strscpy()] Signed-off-by:
-
Jouni Malinen authored
commit 3e493173 upstream. The Layer 2 Update frame is used to update bridges when a station roams to another AP even if that STA does not transmit any frames after the reassociation. This behavior was described in IEEE Std 802.11F-2003 as something that would happen based on MLME-ASSOCIATE.indication, i.e., before completing 4-way handshake. However, this IEEE trial-use recommended practice document was published before RSN (IEEE Std 802.11i-2004) and as such, did not consider RSN use cases. Furthermore, IEEE Std 802.11F-2003 was withdrawn in 2006 and as such, has not been maintained amd should not be used anymore. Sending out the Layer 2 Update frame immediately after association is fine for open networks (and also when using SAE, FT protocol, or FILS authentication when the station is actually authenticated by the time association completes). However, it is not appropriate for cases where RSN is used with PSK or EAP authentication since the station is actually fully authenticated only once the 4-way handshake completes after authentication and attackers might be able to use the unauthenticated triggering of Layer 2 Update frame transmission to disrupt bridge behavior. Fix this by postponing transmission of the Layer 2 Update frame from station entry addition to the point when the station entry is marked authorized. Similarly, send out the VLAN binding update only if the STA entry has already been authorized. Signed-off-by:
Jouni Malinen <jouni@codeaurora.org> Reviewed-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Dedy Lansky authored
commit 30ca1aa5 upstream. Make ieee80211_send_layer2_update() a common function so other drivers can re-use it. Signed-off-by:
Dedy Lansky <dlansky@codeaurora.org> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> [bwh: Backported to 4.9 as dependency of commit 3e493173 "mac80211: Do not send Layer 2 Update frame before authorization": - Retain type-casting of skb_put() return value - Adjust context] Signed-off-by:
-
Laura Abbott authored
commit 82034c23 upstream. Commit 15122ee2 ("arm64: Enforce BBM for huge IO/VMAP mappings") disallowed block mappings for ioremap since that code does not honor break-before-make. The same APIs are also used for permission updating though and the extra checks prevent the permission updates from happening, even though this should be permitted. This results in read-only permissions not being fully applied. Visibly, this can occasionaly be seen as a failure on the built in rodata test when the test data ends up in a section or as an odd RW gap on the page table dump. Fix this by using pgattr_change_is_safe instead of p*d_present for determining if the change is permitted. Reviewed-by:
Kees Cook <keescook@chromium.org> Tested-by:
Peter Robinson <pbrobinson@gmail.com> Reported-by:
Laura Abbott <labbott@redhat.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Will Deacon authored
commit 15122ee2 upstream. ioremap_page_range doesn't honour break-before-make and attempts to put down huge mappings (using p*d_set_huge) over the top of pre-existing table entries. This leads to us leaking page table memory and also gives rise to TLB conflicts and spurious aborts, which have been seen in practice on Cortex-A75. Until this has been resolved, refuse to put block mappings when the existing entry is found to be present. Fixes: 324420bf ("arm64: add support for ioremap() block mappings") Reported-by:
Hanjun Guo <hanjun.guo@linaro.org> Reported-by:
Lei Li <lious.lilei@hisilicon.com> Acked-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Ben Hutchings authored
This is preparation for the following backported fixes. It was done upstream as part of commit 20a004e7 "arm64: mm: Use READ_ONCE/WRITE_ONCE when accessing page tables", the rest of which does not seem suitable for stable. Signed-off-by:
-
Kristina Martsenko authored
commit 19338304 upstream. Instead of open coding the generation of page table entries, use the macros/functions that exist for this - pfn_p*d and p*d_populate. Most code in the kernel already uses these macros, this patch tries to fix up the few places that don't. This is useful for the next patch in this series, which needs to change the page table entry logic, and it's better to have that logic in one place. The KVM extended ID map is special, since we're creating a level above CONFIG_PGTABLE_LEVELS and the required function isn't available. Leave it as is and add a comment to explain it. (The normal kernel ID map code doesn't need this change because its page tables are created in assembly (__create_page_tables)). Tested-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Reviewed-by:
Marc Zyngier <marc.zyngier@arm.com> Tested-by:
Bob Picco <bob.picco@oracle.com> Reviewed-by:
Kristina Martsenko <kristina.martsenko@arm.com> Signed-off-by:
-
Ard Biesheuvel authored
commit e98216b5 upstream. Now that we take care not manipulate the live kernel page tables in a way that may lead to TLB conflicts, the case where a table mapping is replaced by a block mapping can no longer occur. So remove the handling of this at the PUD and PMD levels, and instead, BUG() on any occurrence of live kernel page table manipulations that modify anything other than the permission bits. Since mark_rodata_ro() is the only caller where the kernel mappings that are being manipulated are actually live, drop the various conditional flush_tlb_all() invocations, and add a single call to mark_rodata_ro() instead. Signed-off-by:
-
Sanjay Konduri authored
commit abd39c6d upstream. Observed crash in some scenarios when assertion has occurred, this is because hw structure is freed and is tried to get accessed in some functions where null check is already present. So, avoided the crash by making the hw to NULL after freeing. Signed-off-by:
Sanjay Konduri <sanjay.konduri@redpinesignals.com> Signed-off-by:
Sushant Kumar Mishra <sushant.mishra@redpinesignals.com> Signed-off-by:
-
Arnd Bergmann authored
commit ad312f95 upstream. The select() implementation is carefully tuned to put a sensible amount of data on the stack for holding a copy of the user space fd_set, but not too large to risk overflowing the kernel stack. When building a 32-bit kernel with clang, we need a little more space than with gcc, which often triggers a warning: fs/select.c:619:5: error: stack frame size of 1048 bytes in function 'core_sys_select' [-Werror,-Wframe-larger-than=] int core_sys_select(int n, fd_set __user *inp, fd_set __user *outp, I experimentally found that for 32-bit ARM, reducing the maximum stack usage by 64 bytes keeps us reliably under the warning limit again. Link: http://lkml.kernel.org/r/20190307090146.1874906-1-arnd@arndb.deSigned-off-by:
Andi Kleen <ak@linux.intel.com> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Cc: Eric Dumazet <edumazet@google.com> Cc: "Darrick J. Wong" <darrick.wong@oracle.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Miles Chen <miles.chen@mediatek.com> Signed-off-by:
-
