- 12 4月, 2022 6 次提交
-
-
由 Ido Schimmel 提交于
stable inclusion from linux-4.19.228 commit e3e01ed702c7b5f5d306c2ef566d30b84aa57126 -------------------------------- commit 6cee105e upstream. The warning messages can be invoked from the data path for every packet transmitted through an ip6gre netdev, leading to high CPU utilization. Fix that by rate limiting the messages. Fixes: 09c6bbf0 ("[IPV6]: Do mandatory IPv6 tunnel endpoint checks in realtime") Reported-by: NMaksym Yaremchuk <maksymy@nvidia.com> Tested-by: NMaksym Yaremchuk <maksymy@nvidia.com> Signed-off-by: NIdo Schimmel <idosch@nvidia.com> Reviewed-by: NAmit Cohen <amcohen@nvidia.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com> Signed-off-by: NLaibin Qiu <qiulaibin@huawei.com>
-
stable inclusion from linux-4.19.228 commit 47bc9be8d6d94a25a598b4056078925dd6d15851 -------------------------------- commit 8838b2af upstream. n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010. See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516 The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to the newer 27.010 here. Chapter 5.2.7.3 states that DC1 (XON) and DC3 (XOFF) are the control characters defined in ISO/IEC 646. These shall be quoted if seen in the data stream to avoid interpretation as flow control characters. ISO/IEC 646 refers to the set of ISO standards described as the ISO 7-bit coded character set for information interchange. Its final version is also known as ITU T.50. See https://www.itu.int/rec/T-REC-T.50-199209-I/en To abide the standard it is needed to quote DC1 and DC3 correctly if these are seen as data bytes and not as control characters. The current implementation already tries to enforce this but fails to catch all defined cases. 3GPP 27.010 chapter 5.2.7.3 clearly states that the most significant bit shall be ignored for DC1 and DC3 handling. The current implementation handles only the case with the most significant bit set 0. Cases in which DC1 and DC3 have the most significant bit set 1 are left unhandled. This patch fixes this by masking the data bytes with ISO_IEC_646_MASK (only the 7 least significant bits set 1) before comparing them with XON (a.k.a. DC1) and XOFF (a.k.a. DC3) when testing which byte values need quotation via byte stuffing. Fixes: e1eaea46 ("tty: n_gsm line discipline") Cc: stable@vger.kernel.org Signed-off-by: NDaniel Starke <daniel.starke@siemens.com> Link: https://lore.kernel.org/r/20220120101857.2509-1-daniel.starke@siemens.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com> Signed-off-by: NLaibin Qiu <qiulaibin@huawei.com>
-
由 Valentin Caron 提交于
stable inclusion from linux-4.19.228 commit a41398a5a1a0dde794c65ef1fa6b2323e2db68bc -------------------------------- commit 037b91ec upstream. x_char is ignored by stm32_usart_start_tx() when xmit buffer is empty. Fix start_tx condition to allow x_char to be sent. Fixes: 48a6092f ("serial: stm32-usart: Add STM32 USART Driver") Cc: stable <stable@vger.kernel.org> Signed-off-by: NErwan Le Ray <erwan.leray@foss.st.com> Signed-off-by: NValentin Caron <valentin.caron@foss.st.com> Link: https://lore.kernel.org/r/20220111164441.6178-3-valentin.caron@foss.st.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com> Signed-off-by: NLaibin Qiu <qiulaibin@huawei.com>
-
由 Robert Hancock 提交于
stable inclusion from linux-4.19.228 commit ff6cb8fc12edee1a4cfe5f2915b06a4d6a5f9d1f -------------------------------- commit d06b1cf2 upstream. 8250_of supports a reg-offset property which is intended to handle cases where the device registers start at an offset inside the region of memory allocated to the device. The Xilinx 16550 UART, for which this support was initially added, requires this. However, the code did not adjust the overall size of the mapped region accordingly, causing the driver to request an area of memory past the end of the device's allocation. For example, if the UART was allocated an address of 0xb0130000, size of 0x10000 and reg-offset of 0x1000 in the device tree, the region of memory reserved was b0131000-b0140fff, which caused the driver for the region starting at b0140000 to fail to probe. Fix this by subtracting reg-offset from the mapped region size. Fixes: b912b5e2 ([POWERPC] Xilinx: of_serial support for Xilinx uart 16550.) Cc: stable <stable@vger.kernel.org> Signed-off-by: NRobert Hancock <robert.hancock@calian.com> Link: https://lore.kernel.org/r/20220112194214.881844-1-robert.hancock@calian.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com> Signed-off-by: NLaibin Qiu <qiulaibin@huawei.com>
-
由 Pablo Neira Ayuso 提交于
stable inclusion from linux-4.19.228 commit a622b1fdfe1c725a6e9cf34d04e92f5c36a99606 -------------------------------- commit 4e1860a3 upstream. IP fragments do not come with the transport header, hence skip bogus layer 4 checksum updates. Fixes: 18140969 ("netfilter: nft_payload: layer 4 checksum adjustment for pseudoheader fields") Reported-and-tested-by: NSteffen Weinreich <steve@weinreich.org> Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: NFlorian Westphal <fw@strlen.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com> Signed-off-by: NLaibin Qiu <qiulaibin@huawei.com>
-
由 Greg Kroah-Hartman 提交于
stable inclusion from linux-4.19.228 commit cf94a8a3ff3d7aa06742f1beb5166fa45ba72122 -------------------------------- commit c9d967b2 upstream. The buffer handling in pm_show_wakelocks() is tricky, and hopefully correct. Ensure it really is correct by using sysfs_emit_at() which handles all of the tricky string handling logic in a PAGE_SIZE buffer for us automatically as this is a sysfs file being read from. Reviewed-by: NLee Jones <lee.jones@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com> Signed-off-by: NLaibin Qiu <qiulaibin@huawei.com>
-
- 11 4月, 2022 3 次提交
-
-
由 Matthias Reichl 提交于
mainline inclusion from mainline-v5.10-rc3 commit 4466d6d2 category: bugfix bugzilla: 82118 CVE: N/A -------------------------------- Commit 2ae0b31e ("tty: don't crash in tty_init_dev when missing tty_port") didn't fully prevent the crash as the cleanup path in tty_init_dev() calls release_tty() which dereferences tty->port without checking it for non-null. Add tty->port checks to release_tty to avoid the kernel crash. Fixes: 2ae0b31e ("tty: don't crash in tty_init_dev when missing tty_port") Signed-off-by: NMatthias Reichl <hias@horus.com> Link: https://lore.kernel.org/r/20201105123432.4448-1-hias@horus.com Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYi Yang <yiyang13@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NLaibin Qiu <qiulaibin@huawei.com>
-
由 Jiri Slaby 提交于
mainline inclusion from mainline-v5.5-rc1 commit 2ae0b31e category: bugfix bugzilla: 82118 CVE: N/A -------------------------------- We currently warn the user when tty->port is not set in tty_init_dev yet. The warning says that the kernel will crash later. And it really will only few lines below at: tty->port->itty = tty; So be nice and avoid the crash -- return an error instead. And update the warning. Signed-off-by: NJiri Slaby <jslaby@suse.cz> Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Link: https://lore.kernel.org/r/20191122101721.7222-1-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYi Yang <yiyang13@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NLaibin Qiu <qiulaibin@huawei.com>
-
由 Nathan Chancellor 提交于
mainline inclusion from mainline-v5.8-rc1 commit 5661dd95 category: bugfix bugzilla: 91291 CVE: N/A -------------------------------- When CONFIG_PRINTK is disabled (e.g. when building allnoconfig), clang warns: ../kernel/printk/printk.c:2416:10: warning: 'sprintf' will always overflow; destination buffer has size 0, but format string expands to at least 33 [-Wfortify-source] len = sprintf(text, ^ 1 warning generated. It is not wrong; text has a zero size when CONFIG_PRINTK is disabled because LOG_LINE_MAX and PREFIX_MAX are both zero. Change to snprintf so that this case is explicitly handled without any risk of overflow. Link: https://github.com/ClangBuiltLinux/linux/issues/846 Link: https://github.com/llvm/llvm-project/commit/6d485ff455ea2b37fef9e06e426dae6c1241b231 Link: http://lkml.kernel.org/r/20200130221644.2273-1-natechancellor@gmail.com Cc: Steven Rostedt <rostedt@goodmis.org> Cc: linux-kernel@vger.kernel.org Cc: clang-built-linux@googlegroups.com Signed-off-by: NNathan Chancellor <natechancellor@gmail.com> Reviewed-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by: NPetr Mladek <pmladek@suse.com> Signed-off-by: NYi Yang <yiyang13@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NLaibin Qiu <qiulaibin@huawei.com>
-
- 02 4月, 2022 13 次提交
-
-
由 Serge Semin 提交于
stable inclusion from linux-4.19.130 commit 0eeaf62981ecc79e8395ca8caa1570eaf3a12257 category: bugfix bugzilla: 89545 CVE: N/A ------------------------------------------------ [ Upstream commit 7b668c06 ] Standard 8250 UART ports are designed in a way so they can communicate with baud rates up to 1/16 of a reference frequency. It's expected from most of the currently supported UART controllers. That's why the former version of serial8250_get_baud_rate() method called uart_get_baud_rate() with min and max baud rates passed as (port->uartclk / 16 / UART_DIV_MAX) and ((port->uartclk + tolerance) / 16) respectively. Doing otherwise, like it was suggested in commit ("serial: 8250_mtk: support big baud rate."), caused acceptance of bauds, which was higher than the normal UART controllers actually supported. As a result if some user-space program requested to set a baud greater than (uartclk / 16) it would have been permitted without truncation, but then serial8250_get_divisor(baud) (which calls uart_get_divisor() to get the reference clock divisor) would have returned a zero divisor. Setting zero divisor will cause an unpredictable effect varying from chip to chip. In case of DW APB UART the communications just stop. Lets fix this problem by getting back the limitation of (uartclk + tolerance) / 16 maximum baud supported by the generic 8250 port. Mediatek 8250 UART ports driver developer shouldn't have touched it in the first place notably seeing he already provided a custom version of set_termios() callback in that glue-driver which took into account the extended baud rate values and accordingly updated the standard and vendor-specific divisor latch registers anyway. Fixes: 81bb549f ("serial: 8250_mtk: support big baud rate.") Signed-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Paul Burton <paulburton@kernel.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Long Cheng <long.cheng@mediatek.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Russell King <linux@armlinux.org.uk> Cc: linux-mips@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Link: https://lore.kernel.org/r/20200506233136.11842-2-Sergey.Semin@baikalelectronics.ruSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYi Yang <yiyang13@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Zhang Qiao 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I50PPU CVE: NA ----------------------------------------------------------------- when unthrottle a cfs_rq at distribute_cfs_runtime(), another cpu may re-throttle this cfs_rq at qos_throttle_cfs_rq() before access the cfs_rq->throttle_list.next, but meanwhile, qos throttle will attach the cfs_rq throttle_list node to percpu qos_throttled_cfs_rq, it will change cfs_rq->throttle_list.next and cause panic or hardlockup at distribute_cfs_runtime(). Fix it by adding a qos_throttle_list node in struct cfs_rq, and qos throttle disuse the cfs_rq->throttle_list. Signed-off-by: NZhang Qiao <zhangqiao22@huawei.com> Reviewed-by: Nzheng zucheng <zhengzucheng@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Linus Torvalds 提交于
mainline inclusion from mainline-v5.18-rc1 commit 901c7280 category: bugfix bugzilla: 186478, https://gitee.com/openeuler/kernel/issues/I4Z86P CVE: CVE-2022-0854 -------------------------------- Halil Pasic points out [1] that the full revert of that commit (revert in bddac7c1), and that a partial revert that only reverts the problematic case, but still keeps some of the cleanups is probably better.  And that partial revert [2] had already been verified by Oleksandr Natalenko to also fix the issue, I had just missed that in the long discussion. So let's reinstate the cleanups from commit aa6f8dcb ("swiotlb: rework "fix info leak with DMA_FROM_DEVICE""), and effectively only revert the part that caused problems. Link: https://lore.kernel.org/all/20220328013731.017ae3e3.pasic@linux.ibm.com/ [1] Link: https://lore.kernel.org/all/20220324055732.GB12078@lst.de/ [2] Link: https://lore.kernel.org/all/4386660.LvFx2qVVIh@natalenko.name/ [3] Suggested-by: NHalil Pasic <pasic@linux.ibm.com> Tested-by: NOleksandr Natalenko <oleksandr@natalenko.name> Cc: Christoph Hellwig" <hch@lst.de> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Conflicts: Documentation/core-api/dma-attributes.rst include/linux/dma-mapping.h kernel/dma/swiotlb.c Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Linus Torvalds 提交于
mainline inclusion from mainline-v5.18-rc1 commit bddac7c1 category: bugfix bugzilla: 186478, https://gitee.com/openeuler/kernel/issues/I4Z86P CVE: CVE-2022-0854 -------------------------------- This reverts commit aa6f8dcb. It turns out this breaks at least the ath9k wireless driver, and possibly others. What the ath9k driver does on packet receive is to set up the DMA transfer with: int ath_rx_init(..) .. bf->bf_buf_addr = dma_map_single(sc->dev, skb->data, common->rx_bufsize, DMA_FROM_DEVICE); and then the receive logic (through ath_rx_tasklet()) will fetch incoming packets static bool ath_edma_get_buffers(..) .. dma_sync_single_for_cpu(sc->dev, bf->bf_buf_addr, common->rx_bufsize, DMA_FROM_DEVICE); ret = ath9k_hw_process_rxdesc_edma(ah, rs, skb->data); if (ret == -EINPROGRESS) { /*let device gain the buffer again*/ dma_sync_single_for_device(sc->dev, bf->bf_buf_addr, common->rx_bufsize, DMA_FROM_DEVICE); return false; } and it's worth noting how that first DMA sync: dma_sync_single_for_cpu(..DMA_FROM_DEVICE); is there to make sure the CPU can read the DMA buffer (possibly by copying it from the bounce buffer area, or by doing some cache flush). The iommu correctly turns that into a "copy from bounce bufer" so that the driver can look at the state of the packets. In the meantime, the device may continue to write to the DMA buffer, but we at least have a snapshot of the state due to that first DMA sync. But that _second_ DMA sync: dma_sync_single_for_device(..DMA_FROM_DEVICE); is telling the DMA mapping that the CPU wasn't interested in the area because the packet wasn't there. In the case of a DMA bounce buffer, that is a no-op. Note how it's not a sync for the CPU (the "for_device()" part), and it's not a sync for data written by the CPU (the "DMA_FROM_DEVICE" part). Or rather, it _should_ be a no-op. That's what commit aa6f8dcb broke: it made the code bounce the buffer unconditionally, and changed the DMA_FROM_DEVICE to just unconditionally and illogically be DMA_TO_DEVICE. [ Side note: purely within the confines of the swiotlb driver it wasn't entirely illogical: The reason it did that odd DMA_FROM_DEVICE -> DMA_TO_DEVICE conversion thing is because inside the swiotlb driver, it uses just a swiotlb_bounce() helper that doesn't care about the whole distinction of who the sync is for - only which direction to bounce. So it took the "sync for device" to mean that the CPU must have been the one writing, and thought it meant DMA_TO_DEVICE. ] Also note how the commentary in that commit was wrong, probably due to that whole confusion, claiming that the commit makes the swiotlb code "bounce unconditionally (that is, also when dir == DMA_TO_DEVICE) in order do avoid synchronising back stale data from the swiotlb buffer" which is nonsensical for two reasons: - that "also when dir == DMA_TO_DEVICE" is nonsensical, as that was exactly when it always did - and should do - the bounce. - since this is a sync for the device (not for the CPU), we're clearly fundamentally not coping back stale data from the bounce buffers at all, because we'd be copying *to* the bounce buffers. So that commit was just very confused. It confused the direction of the synchronization (to the device, not the cpu) with the direction of the DMA (from the device). Reported-and-bisected-by: NOleksandr Natalenko <oleksandr@natalenko.name> Reported-by: NOlha Cherevyk <olha.cherevyk@gmail.com> Cc: Halil Pasic <pasic@linux.ibm.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Kalle Valo <kvalo@kernel.org> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Toke Høiland-Jørgensen <toke@toke.dk> Cc: Maxime Bizon <mbizon@freebox.fr> Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Conflicts: Documentation/core-api/dma-attributes.rst include/linux/dma-mapping.h kernel/dma/swiotlb.c Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Szymon Heidrich 提交于
mainline inclusion from mainline-v5.17-rc4 commit 7f14c722 category: bugfix bugzilla: 186427, https://gitee.com/openeuler/kernel/issues/I4ZWQA CVE: CVE-2022-27223 -------------------------------- Assure that host may not manipulate the index to point past endpoint array. Signed-off-by: NSzymon Heidrich <szymon.heidrich@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLijun Fang <fanglijun3@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Oliver Neukum 提交于
mainline inclusion from mainline-v5.17-rc4 commit e9da0b56 category: bugfix bugzilla: 186472, https://gitee.com/openeuler/kernel/issues/I4ZWKH CVE: CVE-2022-26966 -------------------------------- A malicious device can leak heap data to user space providing bogus frame lengths. Introduce a sanity check. Signed-off-by: NOliver Neukum <oneukum@suse.com> Reviewed-by: NGrant Grundler <grundler@chromium.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NLijun Fang <fanglijun3@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Roberto Sassu 提交于
stable inclusion from stable-v4.19.125 commit 657a03ff6c97319d8e664c05a1beebd8eb15d049 category: bugfix bugzilla: 91661, https://gitee.com/openeuler/kernel/issues/I5047U CVE: NA ----------------------------------------------------------------- [ Upstream commit 2e3a34e9 ] This patch fixes the return value of ima_write_policy() when a new policy is directly passed to IMA and the current policy requires appraisal of the file containing the policy. Currently, if appraisal is not in ENFORCE mode, ima_write_policy() returns 0 and leads user space applications to an endless loop. Fix this issue by denying the operation regardless of the appraisal mode. Cc: stable@vger.kernel.org # 4.10.x Fixes: 19f8a847 ("ima: measure and appraise the IMA policy itself") Signed-off-by: NRoberto Sassu <roberto.sassu@huawei.com> Reviewed-by: NKrzysztof Struczynski <krzysztof.struczynski@huawei.com> Signed-off-by: NMimi Zohar <zohar@linux.ibm.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NWang Weiyang <wangweiyang2@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Roberto Sassu 提交于
stable inclusion from stable-v4.19.164 commit 709ed96f6ef2b040a0ea9274b4d67ce61a095eb3 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5047U CVE: NA ----------------------------------------------------------------- commit 207cdd56 upstream. Commit a408e4a8 ("ima: open a new file instance if no read permissions") already introduced a second open to measure a file when the original file descriptor does not allow it. However, it didn't remove the existing method of changing the mode of the original file descriptor, which is still necessary if the current process does not have enough privileges to open a new one. Changing the mode isn't really an option, as the filesystem might need to do preliminary steps to make the read possible. Thus, this patch removes the code and keeps the second open as the only option to measure a file when it is unreadable with the original file descriptor. Cc: <stable@vger.kernel.org> # 4.20.x: 0014cc04 ima: Set file->f_mode Fixes: 2fe5d6de ("ima: integrity appraisal extension") Signed-off-by: NRoberto Sassu <roberto.sassu@huawei.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NMimi Zohar <zohar@linux.ibm.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NWang Weiyang <wangweiyang2@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Roberto Sassu 提交于
stable inclusion from stable-v4.19.125 commit 904de138bae903a6e377322e64312e22a84f2140 category: bugfix bugzilla: 91657, https://gitee.com/openeuler/kernel/issues/I5047U CVE: NA ----------------------------------------------------------------- [ Upstream commit 0014cc04 ] Commit a408e4a8 ("ima: open a new file instance if no read permissions") tries to create a new file descriptor to calculate a file digest if the file has not been opened with O_RDONLY flag. However, if a new file descriptor cannot be obtained, it sets the FMODE_READ flag to file->f_flags instead of file->f_mode. This patch fixes this issue by replacing f_flags with f_mode as it was before that commit. Cc: stable@vger.kernel.org # 4.20.x Fixes: a408e4a8 ("ima: open a new file instance if no read permissions") Signed-off-by: NRoberto Sassu <roberto.sassu@huawei.com> Reviewed-by: NGoldwyn Rodrigues <rgoldwyn@suse.com> Signed-off-by: NMimi Zohar <zohar@linux.ibm.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NWang Weiyang <wangweiyang2@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Roberto Sassu 提交于
stable inclusion from stable-v4.19.169 commit de581e41716795ce93506f3e5b0200048aa4439c category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5047U CVE: NA ----------------------------------------------------------------- commit 8b8c704d upstream. Commit 6cc7c266 ("ima: Call ima_calc_boot_aggregate() in ima_eventdigest_init()") added a call to ima_calc_boot_aggregate() so that the digest can be recalculated for the boot_aggregate measurement entry if the 'd' template field has been requested. For the 'd' field, only SHA1 and MD5 digests are accepted. Given that ima_eventdigest_init() does not have the __init annotation, all functions called should not have it. This patch removes __init from ima_pcrread(). Cc: stable@vger.kernel.org Fixes: 6cc7c266 ("ima: Call ima_calc_boot_aggregate() in ima_eventdigest_init()") Reported-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NRoberto Sassu <roberto.sassu@huawei.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NWang Weiyang <wangweiyang2@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Roberto Sassu 提交于
stable inclusion from stable-v4.19.129 commit fcb067cb457e2326c6d759e346f5f5dfef351d50 category: bugfix bugzilla: 89622, https://gitee.com/openeuler/kernel/issues/I5047U CVE: NA ----------------------------------------------------------------- [ Upstream commit 6cc7c266 ] If the template field 'd' is chosen and the digest to be added to the measurement entry was not calculated with SHA1 or MD5, it is recalculated with SHA1, by using the passed file descriptor. However, this cannot be done for boot_aggregate, because there is no file descriptor. This patch adds a call to ima_calc_boot_aggregate() in ima_eventdigest_init(), so that the digest can be recalculated also for the boot_aggregate entry. Cc: stable@vger.kernel.org # 3.13.x Fixes: 3ce1217d ("ima: define template fields library and new helpers") Reported-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NRoberto Sassu <roberto.sassu@huawei.com> Signed-off-by: NMimi Zohar <zohar@linux.ibm.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Conflicts: security/integrity/ima/ima_crypto.c Signed-off-by: NWang Weiyang <wangweiyang2@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Roberto Sassu 提交于
stable inclusion from stable-v4.19.155 commit 05f703b07727c0eb81f487143b583d5f8561d900 category: bugfix bugzilla: 83797, https://gitee.com/openeuler/kernel/issues/I5047U CVE: NA ----------------------------------------------------------------- commit 455b6c91 upstream. This patch checks the size for the EVM_IMA_XATTR_DIGSIG and EVM_XATTR_PORTABLE_DIGSIG types to ensure that the algorithm is read from the buffer returned by vfs_getxattr_alloc(). Cc: stable@vger.kernel.org # 4.19.x Fixes: 5feeb611 ("evm: Allow non-SHA1 digital signatures") Signed-off-by: NRoberto Sassu <roberto.sassu@huawei.com> Signed-off-by: NMimi Zohar <zohar@linux.ibm.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NWang Weiyang <wangweiyang2@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Roberto Sassu 提交于
stable inclusion from stable-v4.19.153 commit c470dc530c9ee6ef4b22fed19c77e20c745564e1 category: bugfix bugzilla: 83782, https://gitee.com/openeuler/kernel/issues/I5047U CVE: NA ----------------------------------------------------------------- commit 60386b85 upstream. Errors returned by crypto_shash_update() are not checked in ima_calc_boot_aggregate_tfm() and thus can be overwritten at the next iteration of the loop. This patch adds a check after calling crypto_shash_update() and returns immediately if the result is not zero. Cc: stable@vger.kernel.org Fixes: 3323eec9 ("integrity: IMA as an integrity service provider") Signed-off-by: NRoberto Sassu <roberto.sassu@huawei.com> Signed-off-by: NMimi Zohar <zohar@linux.ibm.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NWang Weiyang <wangweiyang2@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
- 30 3月, 2022 3 次提交
-
-
由 Ma Wupeng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4SK3S CVE: NA -------------------------------- Commit 45bd608e ("mm: Introduce watermark check for memory reliable") introduce watermark to reserve memory in mirrored region for kernel usage. But this value does not interact well with kswapd and this will lead to fallback to non-mirrored region without release pagecache in mirrored region. With this patch, watermark is set to zero to avoid this problem. Memory allocation with ___GFP_RELIABILITY will fallback to non-mirrored region if zone's low watermark is reached and kswapd will be awakened at this time. Signed-off-by: NMa Wupeng <mawupeng1@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Ma Wupeng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4SK3S CVE: NA -------------------------------- If memory reliable watermark is far greater than zone's default watermark, reliable memory allocation will trigger oom without wake up kswapd to release pagecache. With this patch, memory reliable watermark will be disabled if memory fallback is disabled. Signed-off-by: NMa Wupeng <mawupeng1@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Ma Wupeng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4SK3S CVE: NA -------------------------------- Previous limit checking are done before real memory allocation. This will lead to some steps in __alloc_pages_slowpath() unreached(kswapd, direct compact and so on). Now limit checking are done in the end of __alloc_pages_nodemask(). Pages will be released if this memory allocation is stopped by limit checking. Memory allocation will fallback to movable zone if one of the following conditions are met: - memory reliable fallback is enabled - global init process Memory allocation with __GFP_NOFAIL will not check any limit. If memory reliable fallback is disabled and gfp flag does not contains any of the following flags: - __GFP_NORETRY - __GFP_RETRY_MAYFAIL - __GFP_THISNODE Or the following conditions are false - current->flags & PF_DUMPCORE - order > PAGE_ALLOC_COSTLY_ORDER Oom will occur to release some memory. Signed-off-by: NMa Wupeng <mawupeng1@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
- 26 3月, 2022 5 次提交
-
-
由 Zheng Yejian 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4ZIB2 CVE: NA -------------------------------- Kernel panic happened on 'arm64 big endian' board after calling function that has been live-patched. It can be reproduced as follows: 1. Insert 'livepatch-sample.ko' to patch kernel function 'cmdline_proc_show'; 2. Enable patch by execute: echo 1 > /sys/kernel/livepatch/livepatch-sample/enabled 3. Call 'cmdline_proc_show' by execute: cat /proc/cmdline 4. Then we get following panic logs: > kernel BUG at arch/arm64/kernel/traps.c:408! > Internal error: Oops - BUG: 0 [#1] SMP > Modules linked in: dump_mem(OE) livepatch_cmdline1(OEK) hi1382_gmac(OE) > [last unloaded: dump_mem] > CPU: 3 PID: 1752 Comm: cat Session: 0 Tainted: G OE K > 5.10.0+ #2 > Hardware name: Hisilicon PhosphorHi1382 (DT) > pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--) > pc : do_undefinstr+0x23c/0x2b4 > lr : do_undefinstr+0x5c/0x2b4 > sp : ffffffc010ac3a80 > x29: ffffffc010ac3a80 x28: ffffff82eb0a8000 > x27: 0000000000000000 x26: 0000000000000001 > x25: 0000000000000000 x24: 0000000000001000 > x23: 0000000000000000 x22: ffffffd0e0f16000 > x21: ffffffd0e0ae7000 x20: ffffffc010ac3b00 > x19: 0000000000021fd6 x18: ffffffd0e04aad94 > x17: 0000000000000000 x16: 0000000000000000 > x15: ffffffd0e04b519c x14: 0000000000000000 > x13: 0000000000000000 x12: 0000000000000000 > x11: 0000000000000000 x10: 0000000000000000 > x9 : 0000000000000000 x8 : 0000000000000000 > x7 : 0000000000000000 x6 : ffffffd0e0f16100 > x5 : 0000000000000000 x4 : 00000000d5300000 > x3 : 0000000000000000 x2 : ffffffd0e0f160f0 > x1 : ffffffd0e0f16103 x0 : 0000000000000005 > Call trace: > do_undefinstr+0x23c/0x2b4 > el1_undef+0x2c/0x44 > el1_sync_handler+0xa4/0xb0 > el1_sync+0x74/0x100 > cmdline_proc_show+0xc/0x44 > proc_reg_read_iter+0xb0/0xc4 > new_sync_read+0x10c/0x15c > vfs_read+0x144/0x18c > ksys_read+0x78/0xe8 > __arm64_sys_read+0x24/0x30 We compare first 6 instructions of 'cmdline_proc_show' before and after patch (see below). There are 4 instructions modified, so this is case that offset between old and new function is out of 128M. And we found that instruction at 'cmdline_proc_show+0xc' seems incorrect (it expects to be '00021fd6'). origin: patched: -------- -------- fd7bbea9 929ff7f0 21d500f0 f2a91b30 fd030091 f2d00010 211040f9 d61f0200 <-- cmdline_proc_show+0xc (expect is '00021fd6') f30b00f9 f30b00f9 f30300aa f30300aa It is caused by an incorrect big-to-little endian conversion, and we correct it. Fixes: 5aa9a1a3 ("livepatch/arm64: support livepatch without ftrace") Signed-off-by: NZheng Yejian <zhengyejian1@huawei.com> Reviewed-by: NKuohai Xu <xukuohai@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Wang ShaoBo 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4SE03 CVE: NA --------------------------------------------------- This makes step entry aligned with step_size*step_cnt but not step_size, and check for alignment before traversing rmid_transform. When modifying rmid with a value not aligned with step_size*step_cnt, for_each_rmid_transform_point_step_from might miss next step point if it has been occupied in case step_cnt or step_size not equals to 1, which will cause the actual allocated rmid to be inconsistent with the expected one. Fixes: b47b9a81 ("arm64/mpam: rmid: refine allocation and release process") Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com> Reviewed-by: NCheng Jian <cj.chengjian@huawei.com> Signed-off-by: NLaibin Qiu <qiulaibin@huawei.com>
-
由 Xingang Wang 提交于
arm64/mpam: refactor device tree structure to support multiple devices ascend inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I49RB2 CVE: NA --------------------------------------------------- To support multiple mpam device nodes, all nodes should be organized as child of the same parent nodes. This makes sure that the mpam discovery start and complete procedure in the right execution order. Add modification in the devicetree documentation to record this. Signed-off-by: NXingang Wang <wangxingang5@huawei.com> Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com> Reviewed-by: NCheng Jian <cj.chengjian@huawei.com> Signed-off-by: NLaibin Qiu <qiulaibin@huawei.com>
-
由 Xingang Wang 提交于
ascend inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I49RB2 CVE: NA --------------------------------------------------- The process of MPAM device tree initialization is like this: arm_mpam_device_probe() // driver probe mpam_discovery_start() // start discover mpam devices [...] // find and add mpam devices mpam_discovery_complete() // trigger mpam_enable When there are multiple mpam device nodes, the driver probe procedure will execute more than once. However, the mpam_discovery_start() and mpam_discovery_complete() should only run once. Besides, the start should run first, and the complete should run after all devices added. So we reorganize the device tree structure, so that there will be only one mpam device parent nodes, and the probe procedure will only run once. We add the child node to represent the mpam devices, and traverse and add all mpam devices in the middle procedure of driver probe. Signed-off-by: NXingang Wang <wangxingang5@huawei.com> Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com> Reviewed-by: NCheng Jian <cj.chengjian@huawei.com> Signed-off-by: NLaibin Qiu <qiulaibin@huawei.com>
-
由 Xingang Wang 提交于
ascend inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I49RB2 CVE: NA --------------------------------------------------- Fix modpost Section mismatch error in __mpam_device_create() and others. These warnings will occur in high version gcc, for example 10.1.0. [...] WARNING: vmlinux.o(.text+0x2ed88): Section mismatch in reference from the function __mpam_device_create() to the function .init.text:mpam_device_alloc() The function __mpam_device_create() references the function __init mpam_device_alloc(). This is often because __mpam_device_create lacks a __init annotation or the annotation of mpam_device_alloc is wrong. WARNING: vmlinux.o(.text.unlikely+0xa5c): Section mismatch in reference from the function mpam_resctrl_init() to the function .init.text:mpam_init_padding() The function mpam_resctrl_init() references the function __init mpam_init_padding(). This is often because mpam_resctrl_init lacks a __init annotation or the annotation of mpam_init_padding is wrong. WARNING: vmlinux.o(.text.unlikely+0x5a9c): Section mismatch in reference from the function resctrl_group_init() to the function .init.text:resctrl_group_setup_root() The function resctrl_group_init() references the function __init resctrl_group_setup_root(). This is often because resctrl_group_init lacks a __init annotation or the annotation of resctrl_group_setup_root is wrong. [...] Fixes: c5e27c39 ("arm64/mpam: remove __init macro to support driver probe") Signed-off-by: NXingang Wang <wangxingang5@huawei.com> Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com> Reviewed-by: NCheng Jian <cj.chengjian@huawei.com> Signed-off-by: NLaibin Qiu <qiulaibin@huawei.com>
-
- 24 3月, 2022 2 次提交
-
-
由 Haimin Zhang 提交于
mainline inclusion from mainline-v5.17-rc5 commit cc8f7fe1 category: bugfix bugzilla: 186474, https://gitee.com/openeuler/kernel/issues/I4Z2LA CVE: CVE-2022-0494 -------------------------------- Add __GFP_ZERO flag for alloc_page in function bio_copy_kern to initialize the buffer of a bio. Signed-off-by: NHaimin Zhang <tcs.kernel@gmail.com> Reviewed-by: NChaitanya Kulkarni <kch@nvidia.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20220216084038.15635-1-tcs.kernel@gmail.comSigned-off-by: NJens Axboe <axboe@kernel.dk> Conflict: commit ce288e05 ("block: remove BLK_BOUNCE_ISA support") is not backported. Signed-off-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Kefeng Wang 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4YTLN CVE: NA -------------------------------- The user wants to reserve a certain amount of memory for normal non-huge page, that is, the hugetlb can't allowed to use all the memory. Add a new kernel parameters "hugepage_prohibit_sz=" to set size for normal non-huge page reserved, and when alloc huge page, let's fail if the new allocating exceeds the limit. Signed-off-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NPeng Liu <liupeng256@huawei.com> Reviewed-by: NChen Wandun <chenwandun@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
- 23 3月, 2022 2 次提交
-
-
由 Halil Pasic 提交于
mainline inclusion from mainline-v5.17-rc8 commit aa6f8dcb category: bugfix bugzilla: 186478, https://gitee.com/openeuler/kernel/issues/I4Z86P CVE: CVE-2022-0854 -------------------------------- Unfortunately, we ended up merging an old version of the patch "fix info leak with DMA_FROM_DEVICE" instead of merging the latest one. Christoph (the swiotlb maintainer), he asked me to create an incremental fix (after I have pointed this out the mix up, and asked him for guidance). So here we go. The main differences between what we got and what was agreed are: * swiotlb_sync_single_for_device is also required to do an extra bounce * We decided not to introduce DMA_ATTR_OVERWRITE until we have exploiters * The implantation of DMA_ATTR_OVERWRITE is flawed: DMA_ATTR_OVERWRITE must take precedence over DMA_ATTR_SKIP_CPU_SYNC Thus this patch removes DMA_ATTR_OVERWRITE, and makes swiotlb_sync_single_for_device() bounce unconditionally (that is, also when dir == DMA_TO_DEVICE) in order do avoid synchronising back stale data from the swiotlb buffer. Let me note, that if the size used with dma_sync_* API is less than the size used with dma_[un]map_*, under certain circumstances we may still end up with swiotlb not being transparent. In that sense, this is no perfect fix either. To get this bullet proof, we would have to bounce the entire mapping/bounce buffer. For that we would have to figure out the starting address, and the size of the mapping in swiotlb_sync_single_for_device(). While this does seem possible, there seems to be no firm consensus on how things are supposed to work. Signed-off-by: NHalil Pasic <pasic@linux.ibm.com> Fixes: ddbd89de ("swiotlb: fix info leak with DMA_FROM_DEVICE") Cc: stable@vger.kernel.org Reviewed-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Conflicts: Documentation/core-api/dma-attributes.rst include/linux/dma-mapping.h kernel/dma/swiotlb.c Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Halil Pasic 提交于
mainline inclusion from mainline-v5.17-rc6 commit ddbd89de category: bugfix bugzilla: 186478, https://gitee.com/openeuler/kernel/issues/I4Z86P CVE: CVE-2022-0854 -------------------------------- The problem I'm addressing was discovered by the LTP test covering cve-2018-1000204. A short description of what happens follows: 1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV and a corresponding dxferp. The peculiar thing about this is that TUR is not reading from the device. 2) In sg_start_req() the invocation of blk_rq_map_user() effectively bounces the user-space buffer. As if the device was to transfer into it. Since commit a45b599a ("scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()") we make sure this first bounce buffer is allocated with GFP_ZERO. 3) For the rest of the story we keep ignoring that we have a TUR, so the device won't touch the buffer we prepare as if the we had a DMA_FROM_DEVICE type of situation. My setup uses a virtio-scsi device and the buffer allocated by SG is mapped by the function virtqueue_add_split() which uses DMA_FROM_DEVICE for the "in" sgs (here scatter-gather and not scsi generics). This mapping involves bouncing via the swiotlb (we need swiotlb to do virtio in protected guest like s390 Secure Execution, or AMD SEV). 4) When the SCSI TUR is done, we first copy back the content of the second (that is swiotlb) bounce buffer (which most likely contains some previous IO data), to the first bounce buffer, which contains all zeros. Then we copy back the content of the first bounce buffer to the user-space buffer. 5) The test case detects that the buffer, which it zero-initialized, ain't all zeros and fails. One can argue that this is an swiotlb problem, because without swiotlb we leak all zeros, and the swiotlb should be transparent in a sense that it does not affect the outcome (if all other participants are well behaved). Copying the content of the original buffer into the swiotlb buffer is the only way I can think of to make swiotlb transparent in such scenarios. So let's do just that if in doubt, but allow the driver to tell us that the whole mapped buffer is going to be overwritten, in which case we can preserve the old behavior and avoid the performance impact of the extra bounce. Signed-off-by: NHalil Pasic <pasic@linux.ibm.com> Signed-off-by: NChristoph Hellwig <hch@lst.de> Conflicts: Documentation/core-api/dma-attributes.rst include/linux/dma-mapping.h kernel/dma/swiotlb.c Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
- 22 3月, 2022 6 次提交
-
-
由 Steffen Klassert 提交于
mainline inclusion from mainline commit ebe48d36 category: bugfix bugzilla: 186409, https://gitee.com/openeuler/kernel/issues/I4Z0V2 CVE: CVE-2022-0886 -------------------------------- The maximum message size that can be send is bigger than the maximum site that skb_page_frag_refill can allocate. So it is possible to write beyond the allocated buffer. Fix this by doing a fallback to COW in that case. v2: Avoid get get_order() costs as suggested by Linus Torvalds. Fixes: cac2661c ("esp4: Avoid skb_cow_data whenever possible") Fixes: 03e2a30f ("esp6: Avoid skb_cow_data whenever possible") Reported-by: Nvalis <sec@valis.email> Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com> Signed-off-by: NXu Jia <xujia39@huawei.com> Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Yunsheng Lin 提交于
mainline inclusion from mainline-v5.15-rc1 commit 723783d0 category: bugfix bugzilla: 186409, https://gitee.com/openeuler/kernel/issues/I4Z0V2 CVE: CVE-2022-0886 -------------------------------- Both SKB_FRAG_PAGE_ORDER are defined to the same value in net/core/sock.c and drivers/vhost/net.c. Move the SKB_FRAG_PAGE_ORDER definition to net/core/sock.h, as both net/core/sock.c and drivers/vhost/net.c include it, and it seems a reasonable file to put the macro. Signed-off-by: NYunsheng Lin <linyunsheng@huawei.com> Acked-by: NJason Wang <jasowang@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NXu Jia <xujia39@huawei.com> conflict: drivers/vhost/net.c Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Luo Meng 提交于
hulk inclusion category: bugfix bugzilla: 186337, https://gitee.com/openeuler/kernel/issues/I4XA09 CVE: NA -------------------------------- If two tasks are running concurrently as follows: task1 | task2 io_uring_enter | io_wqe_worker io_submit_sqes | io_submit_sqe | io_queue_sqe | io_req_defer | io_req_defer_prep | io_prep_work_files | io_grab_files | req->work.files = current->files | io_queue_async_work | __io_queue_async_work | io_wq_enqueue | io_wqe_insert_work | | io_worker_handle_work | io_impersonate_work | current->files = work->files And then, one of the concurrency UAF can be shown as below: free use (task3 ls -l /proc/io_wqe_worker id/fd ) do_exit // tsk = current = work->files | exit_files | put_files_struct | tsk->files // tsk->files = work->files | | iterate_dir | proc_readfd_common | p = get_proc_task(file_inode(file)) | get_files_struct | files = task->files | atomic_inc(&files->count) The root cause of UAF bugs is when get req->work.files doesn't add refcount. The mainline commit 0f212204(io_uring: don't rely on weak ->files references) fixes this problem, based on this commit to resolved the problme. Signed-off-by: NLuo Meng <luomeng12@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Qian Cai 提交于
mainline inclusion from mainline-v5.6-rc4 commit 4982bff1 category: bugfix bugzilla: 186464, https://gitee.com/openeuler/kernel/issues/I4YYIZ -------------------------------- In xfs_da3_path_shift() "blk" can be assigned to state->path.blk[-1] if state->path.active is 1 (which is a valid state) when it tries to add an entry to a single dir leaf block and then to shift forward to see if there's a sibling block that would be a better place to put the new entry. This causes a UBSAN warning given negative array indices are undefined behavior in C. In practice the warning is entirely harmless given that "blk" is never dereferenced in this case, but it is still better to fix up the warning and slightly improve the code. UBSAN: Undefined behaviour in fs/xfs/libxfs/xfs_da_btree.c:1989:14 index -1 is out of range for type 'xfs_da_state_blk_t [5]' Call trace: dump_backtrace+0x0/0x2c8 show_stack+0x20/0x2c dump_stack+0xe8/0x150 __ubsan_handle_out_of_bounds+0xe4/0xfc xfs_da3_path_shift+0x860/0x86c [xfs] xfs_da3_node_lookup_int+0x7c8/0x934 [xfs] xfs_dir2_node_addname+0x2c8/0xcd0 [xfs] xfs_dir_createname+0x348/0x38c [xfs] xfs_create+0x6b0/0x8b4 [xfs] xfs_generic_create+0x12c/0x1f8 [xfs] xfs_vn_mknod+0x3c/0x4c [xfs] xfs_vn_create+0x34/0x44 [xfs] do_last+0xd4c/0x10c8 path_openat+0xbc/0x2f4 do_filp_open+0x74/0xf4 do_sys_openat2+0x98/0x180 __arm64_sys_openat+0xf8/0x170 do_el0_svc+0x170/0x240 el0_sync_handler+0x150/0x250 el0_sync+0x164/0x180 Suggested-by: NChristoph Hellwig <hch@infradead.org> Signed-off-by: NQian Cai <cai@lca.pw> Reviewed-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com> Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com> Signed-off-by: NGuo Xuenan <guoxuenan@huawei.com> Conflicts: fs/xfs/libxfs/xfs_da_btree.c Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Jia-Ju Bai 提交于
mainline inclusion from mainline-v5.3-rc2 commit afa1d96d category: bugfix bugzilla: 186464, https://gitee.com/openeuler/kernel/issues/I4YYIZ -------------------------------- In xchk_da_btree_block_check_sibling(), there is an if statement on line 274 to check whether ds->state->altpath.blk[level].bp is NULL: if (ds->state->altpath.blk[level].bp) When ds->state->altpath.blk[level].bp is NULL, it is used on line 281: xfs_trans_brelse(..., ds->state->altpath.blk[level].bp); struct xfs_buf_log_item *bip = bp->b_log_item; ASSERT(bp->b_transp == tp); Thus, possible null-pointer dereferences may occur. To fix these bugs, ds->state->altpath.blk[level].bp is checked before being used. These bugs are found by a static analysis tool STCheck written by us. Signed-off-by: NJia-Ju Bai <baijiaju1990@gmail.com> Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com> Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com> Signed-off-by: NGuo Xuenan <guoxuenan@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Brian Foster 提交于
mainline inclusion from mainline-v5.1-rc5 commit 4d09807f category: bugfix bugzilla: 186464, https://gitee.com/openeuler/kernel/issues/I4YYIZ -------------------------------- The xfs_buf_log_item ->iop_unlock() callback asserts that the buffer is unlocked when either non-stale or aborted. This assert occurs after the bli refcount has been dropped and the log item potentially freed. The aborted check is thus a potential use after free. This problem has been reproduced with KASAN enabled via generic/475. Fix up xfs_buf_item_unlock() to query aborted state before the bli reference is dropped to prevent a potential use after free. Signed-off-by: NBrian Foster <bfoster@redhat.com> Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com> Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com> Signed-off-by: NGuo Xuenan <guoxuenan@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-