- Kernel - mailweb.openeuler.org

[openeuler:OLK-6.6] BUILD REGRESSION b681a3319371ee8ba71579a3b546dda7d7b4a902
by kernel test robot 06 Jun '24

06 Jun '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-6.6 branch HEAD: b681a3319371ee8ba71579a3b546dda7d7b4a902 !8621 LoongArch: fix HT RX INT TRANS register not initialized Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- arm64-defconfig | |-- arch-arm64-kernel-cpufeature.c:warning:enable_pseudo_nmi-defined-but-not-used | `-- arch-arm64-kvm-vgic-vgic-mmio.c:warning:variable-is_pending-set-but-not-used |-- arm64-randconfig-001-20240605 | `-- arch-arm64-kvm-vgic-vgic-mmio.c:warning:variable-is_pending-set-but-not-used |-- loongarch-allnoconfig | `-- drivers-irqchip-irq-loongson-eiointc.c:error:NODES_PER_FLATMODE_NODE-undeclared-(first-use-in-this-function) `-- loongarch-randconfig-002-20240605 `-- drivers-irqchip-irq-loongson-eiointc.c:error:NODES_PER_FLATMODE_NODE-undeclared-(first-use-in-this-function) clang_recent_errors `-- arm64-allmodconfig `-- arch-arm64-kvm-vgic-vgic-mmio.c:warning:variable-is_pending-set-but-not-used elapsed time: 854m configs tested: 40 configs skipped: 126 tested configs: arm64 allmodconfig clang arm64 allnoconfig gcc arm64 defconfig gcc arm64 randconfig-001-20240605 gcc arm64 randconfig-002-20240605 clang arm64 randconfig-003-20240605 clang arm64 randconfig-004-20240605 clang loongarch allmodconfig gcc loongarch allnoconfig gcc loongarch defconfig gcc loongarch randconfig-001-20240605 gcc loongarch randconfig-002-20240605 gcc x86_64 allnoconfig clang x86_64 allyesconfig clang x86_64 buildonly-randconfig-001-20240605 gcc x86_64 buildonly-randconfig-002-20240605 gcc x86_64 buildonly-randconfig-003-20240605 gcc x86_64 buildonly-randconfig-004-20240605 clang x86_64 buildonly-randconfig-005-20240605 clang x86_64 buildonly-randconfig-006-20240605 clang x86_64 defconfig gcc x86_64 randconfig-001-20240605 clang x86_64 randconfig-002-20240605 clang x86_64 randconfig-003-20240605 gcc x86_64 randconfig-004-20240605 clang x86_64 randconfig-005-20240605 clang x86_64 randconfig-006-20240605 gcc x86_64 randconfig-011-20240605 clang x86_64 randconfig-012-20240605 gcc x86_64 randconfig-013-20240605 clang x86_64 randconfig-014-20240605 gcc x86_64 randconfig-015-20240605 clang x86_64 randconfig-016-20240605 gcc x86_64 randconfig-071-20240605 gcc x86_64 randconfig-072-20240605 clang x86_64 randconfig-073-20240605 gcc x86_64 randconfig-074-20240605 gcc x86_64 randconfig-075-20240605 gcc x86_64 randconfig-076-20240605 gcc x86_64 rhel-8.3-rust clang -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-1.0-LTS] media: imon: fix access to invalid resource for the second interface
by dinglongwei 05 Jun '24

05 Jun '24

From: Takashi Iwai <tiwai(a)suse.de> stable inclusion from stable-v5.10.202 commit 0f5068519f89d928d6c51100e4b274479123829f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9R4N0 CVE: CVE-2023-52754 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a1766a4fd83befa0b34d932d532e7ebb7fab1fa7 ] imon driver probes two USB interfaces, and at the probe of the second interface, the driver assumes blindly that the first interface got bound with the same imon driver. It's usually true, but it's still possible that the first interface is bound with another driver via a malformed descriptor. Then it may lead to a memory corruption, as spotted by syzkaller; imon driver accesses the data from drvdata as struct imon_context object although it's a completely different one that was assigned by another driver. This patch adds a sanity check -- whether the first interface is really bound with the imon driver or not -- for avoiding the problem above at the probe time. Reported-by: syzbot+59875ffef5cb9c9b29e9(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/000000000000a838aa0603cc74d6@google.com/ Tested-by: Ricardo B. Marliere <ricardo(a)marliere.net> Link: https://lore.kernel.org/r/20230922005152.163640-1-ricardo@marliere.net Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sean Young <sean(a)mess.org> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/media/rc/imon.c [Fix context] Signed-off-by: dinglongwei <dinglongwei1(a)huawei.com> --- drivers/media/rc/imon.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c index 6b10363fb6f0..4dfaa791888c 100644 --- a/drivers/media/rc/imon.c +++ b/drivers/media/rc/imon.c @@ -2394,6 +2394,12 @@ static int imon_probe(struct usb_interface *interface, goto fail; } + if (first_if->dev.driver != interface->dev.driver) { + dev_err(&interface->dev, "inconsistent driver matching\n"); + ret = -EINVAL; + goto fail; + } + first_if_ctx = usb_get_intfdata(first_if); if (ifnum == 0) { -- 2.17.1

2 1

[PATCH openEuler-1.0-LTS] regmap: Fix possible double-free in regcache_rbtree_exit()
by dinglongwei 05 Jun '24

05 Jun '24

From: Yang Yingliang <yangyingliang(a)huawei.com> stable inclusion from stable-v4.19.215 commit 3dae1a4eced3ee733d7222e69b8a55caf2d61091 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9RD9Z CVE: CVE-2021-47483 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 55e6d8037805b3400096d621091dfbf713f97e83 upstream. In regcache_rbtree_insert_to_block(), when 'present' realloc failed, the 'blk' which is supposed to assign to 'rbnode->block' will be freed, so 'rbnode->block' points a freed memory, in the error handling path of regcache_rbtree_init(), 'rbnode->block' will be freed again in regcache_rbtree_exit(), KASAN will report double-free as follows: BUG: KASAN: double-free or invalid-free in kfree+0xce/0x390 Call Trace: slab_free_freelist_hook+0x10d/0x240 kfree+0xce/0x390 regcache_rbtree_exit+0x15d/0x1a0 regcache_rbtree_init+0x224/0x2c0 regcache_init+0x88d/0x1310 __regmap_init+0x3151/0x4a80 __devm_regmap_init+0x7d/0x100 madera_spi_probe+0x10f/0x333 [madera_spi] spi_probe+0x183/0x210 really_probe+0x285/0xc30 To fix this, moving up the assignment of rbnode->block to immediately after the reallocation has succeeded so that the data structure stays valid even if the second reallocation fails. Reported-by: Hulk Robot <hulkci(a)huawei.com> Fixes: 3f4ff561bc88b ("regmap: rbtree: Make cache_present bitmap per node") Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Link: https://lore.kernel.org/r/20211012023735.1632786-1-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/base/regmap/regcache-rbtree.c [Fix context] Signed-off-by: dinglongwei <dinglongwei1(a)huawei.com> --- drivers/base/regmap/regcache-rbtree.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/base/regmap/regcache-rbtree.c b/drivers/base/regmap/regcache-rbtree.c index 09580b1448bc..b6f8f4059e25 100644 --- a/drivers/base/regmap/regcache-rbtree.c +++ b/drivers/base/regmap/regcache-rbtree.c @@ -295,14 +295,14 @@ static int regcache_rbtree_insert_to_block(struct regmap *map, if (!blk) return -ENOMEM; + rbnode->block = blk; + if (BITS_TO_LONGS(blklen) > BITS_TO_LONGS(rbnode->blklen)) { present = krealloc(rbnode->cache_present, BITS_TO_LONGS(blklen) * sizeof(*present), map->alloc_flags); - if (!present) { - kfree(blk); + if (!present) return -ENOMEM; - } memset(present + BITS_TO_LONGS(rbnode->blklen), 0, (BITS_TO_LONGS(blklen) - BITS_TO_LONGS(rbnode->blklen)) @@ -319,7 +319,6 @@ static int regcache_rbtree_insert_to_block(struct regmap *map, } /* update the rbnode block, its size and the base register */ - rbnode->block = blk; rbnode->blklen = blklen; rbnode->base_reg = base_reg; rbnode->cache_present = present; -- 2.17.1

2 1

[PATCH openEuler-1.0-LTS] isdn: mISDN: Fix sleeping function called from invalid context
by dinglongwei 05 Jun '24

05 Jun '24

From: Zheyu Ma <zheyuma97(a)gmail.com> stable inclusion from stable-v4.19.214 commit a5b34409d3fc52114c828be4adbc30744fa3258b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9RC2J CVE: CVE-2021-47468 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 6510e80a0b81b5d814e3aea6297ba42f5e76f73c ] The driver can call card->isac.release() function from an atomic context. Fix this by calling this function after releasing the lock. The following log reveals it: [ 44.168226 ] BUG: sleeping function called from invalid context at kernel/workqueue.c:3018 [ 44.168941 ] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 5475, name: modprobe [ 44.169574 ] INFO: lockdep is turned off. [ 44.169899 ] irq event stamp: 0 [ 44.170160 ] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [ 44.170627 ] hardirqs last disabled at (0): [<ffffffff814209ed>] copy_process+0x132d/0x3e00 [ 44.171240 ] softirqs last enabled at (0): [<ffffffff81420a1a>] copy_process+0x135a/0x3e00 [ 44.171852 ] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 44.172318 ] Preemption disabled at: [ 44.172320 ] [<ffffffffa009b0a9>] nj_release+0x69/0x500 [netjet] [ 44.174441 ] Call Trace: [ 44.174630 ] dump_stack_lvl+0xa8/0xd1 [ 44.174912 ] dump_stack+0x15/0x17 [ 44.175166 ] ___might_sleep+0x3a2/0x510 [ 44.175459 ] ? nj_release+0x69/0x500 [netjet] [ 44.175791 ] __might_sleep+0x82/0xe0 [ 44.176063 ] ? start_flush_work+0x20/0x7b0 [ 44.176375 ] start_flush_work+0x33/0x7b0 [ 44.176672 ] ? trace_irq_enable_rcuidle+0x85/0x170 [ 44.177034 ] ? kasan_quarantine_put+0xaa/0x1f0 [ 44.177372 ] ? kasan_quarantine_put+0xaa/0x1f0 [ 44.177711 ] __flush_work+0x11a/0x1a0 [ 44.177991 ] ? flush_work+0x20/0x20 [ 44.178257 ] ? lock_release+0x13c/0x8f0 [ 44.178550 ] ? __kasan_check_write+0x14/0x20 [ 44.178872 ] ? do_raw_spin_lock+0x148/0x360 [ 44.179187 ] ? read_lock_is_recursive+0x20/0x20 [ 44.179530 ] ? __kasan_check_read+0x11/0x20 [ 44.179846 ] ? do_raw_spin_unlock+0x55/0x900 [ 44.180168 ] ? ____kasan_slab_free+0x116/0x140 [ 44.180505 ] ? _raw_spin_unlock_irqrestore+0x41/0x60 [ 44.180878 ] ? skb_queue_purge+0x1a3/0x1c0 [ 44.181189 ] ? kfree+0x13e/0x290 [ 44.181438 ] flush_work+0x17/0x20 [ 44.181695 ] mISDN_freedchannel+0xe8/0x100 [ 44.182006 ] isac_release+0x210/0x260 [mISDNipac] [ 44.182366 ] nj_release+0xf6/0x500 [netjet] [ 44.182685 ] nj_remove+0x48/0x70 [netjet] [ 44.182989 ] pci_device_remove+0xa9/0x250 Signed-off-by: Zheyu Ma <zheyuma97(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: dinglongwei <dinglongwei1(a)huawei.com> --- drivers/isdn/hardware/mISDN/netjet.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/isdn/hardware/mISDN/netjet.c b/drivers/isdn/hardware/mISDN/netjet.c index 448370da2c3f..4a342daac98d 100644 --- a/drivers/isdn/hardware/mISDN/netjet.c +++ b/drivers/isdn/hardware/mISDN/netjet.c @@ -963,8 +963,8 @@ nj_release(struct tiger_hw *card) nj_disable_hwirq(card); mode_tiger(&card->bc[0], ISDN_P_NONE); mode_tiger(&card->bc[1], ISDN_P_NONE); - card->isac.release(&card->isac); spin_unlock_irqrestore(&card->lock, flags); + card->isac.release(&card->isac); release_region(card->base, card->base_s); card->base_s = 0; } -- 2.17.1

2 1

[PATCH openEuler-1.0-LTS] usb: dwc2: fix possible NULL pointer dereference caused by driver concurrency
by dinglongwei 05 Jun '24

05 Jun '24

From: Jia-Ju Bai <baijiaju(a)buaa.edu.cn> stable inclusion from stable-v4.19.299 commit fed492aa6493a91a77ebd51da6fb939c98d94a0d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9RFRD CVE: CVE-2023-52855 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ef307bc6ef04e8c1ea843231db58e3afaafa9fa6 ] In _dwc2_hcd_urb_enqueue(), "urb->hcpriv = NULL" is executed without holding the lock "hsotg->lock". In _dwc2_hcd_urb_dequeue(): spin_lock_irqsave(&hsotg->lock, flags); ... if (!urb->hcpriv) { dev_dbg(hsotg->dev, "## urb->hcpriv is NULL ##\n"); goto out; } rc = dwc2_hcd_urb_dequeue(hsotg, urb->hcpriv); // Use urb->hcpriv ... out: spin_unlock_irqrestore(&hsotg->lock, flags); When _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() are concurrently executed, the NULL check of "urb->hcpriv" can be executed before "urb->hcpriv = NULL". After urb->hcpriv is NULL, it can be used in the function call to dwc2_hcd_urb_dequeue(), which can cause a NULL pointer dereference. This possible bug is found by an experimental static analysis tool developed by myself. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. The above possible bug is reported, when my tool analyzes the source code of Linux 6.5. To fix this possible bug, "urb->hcpriv = NULL" should be executed with holding the lock "hsotg->lock". After using this patch, my tool never reports the possible bug, with the kernelconfiguration allyesconfig for x86_64. Because I have no associated hardware, I cannot test the patch in runtime testing, and just verify it according to the code logic. Fixes: 33ad261aa62b ("usb: dwc2: host: spinlock urb_enqueue") Signed-off-by: Jia-Ju Bai <baijiaju(a)buaa.edu.cn> Link: https://lore.kernel.org/r/20230926024404.832096-1-baijiaju@buaa.edu.cn Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: dinglongwei <dinglongwei1(a)huawei.com> --- drivers/usb/dwc2/hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c index 2fe0b953921f..8b8c113b7267 100644 --- a/drivers/usb/dwc2/hcd.c +++ b/drivers/usb/dwc2/hcd.c @@ -4844,8 +4844,8 @@ static int _dwc2_hcd_urb_enqueue(struct usb_hcd *hcd, struct urb *urb, if (qh_allocated && qh->channel && qh->channel->qh == qh) qh->channel->qh = NULL; fail2: - spin_unlock_irqrestore(&hsotg->lock, flags); urb->hcpriv = NULL; + spin_unlock_irqrestore(&hsotg->lock, flags); kfree(qtd); qtd = NULL; fail1: -- 2.17.1

2 1

[PATCH openEuler-1.0-LTS] usb: fix various gadget panics on 10gbps cabling
by Xiang Yang 05 Jun '24

05 Jun '24

From: Maciej Żenczykowski <maze(a)google.com> stable inclusion from stable-v4.19.195 commit 45f9a2fe737dc0a5df270787f2231aee8985cd59 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9R49O CVE: CVE-2021-47267 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 032e288097a553db5653af552dd8035cd2a0ba96 upstream. usb_assign_descriptors() is called with 5 parameters, the last 4 of which are the usb_descriptor_header for: full-speed (USB1.1 - 12Mbps [including USB1.0 low-speed @ 1.5Mbps), high-speed (USB2.0 - 480Mbps), super-speed (USB3.0 - 5Gbps), super-speed-plus (USB3.1 - 10Gbps). The differences between full/high/super-speed descriptors are usually substantial (due to changes in the maximum usb block size from 64 to 512 to 1024 bytes and other differences in the specs), while the difference between 5 and 10Gbps descriptors may be as little as nothing (in many cases the same tuning is simply good enough). However if a gadget driver calls usb_assign_descriptors() with a NULL descriptor for super-speed-plus and is then used on a max 10gbps configuration, the kernel will crash with a null pointer dereference, when a 10gbps capable device port + cable + host port combination shows up. (This wouldn't happen if the gadget max-speed was set to 5gbps, but it of course defaults to the maximum, and there's no real reason to artificially limit it) The fix is to simply use the 5gbps descriptor as the 10gbps descriptor, if a 10gbps descriptor wasn't provided. Obviously this won't fix the problem if the 5gbps descriptor is also NULL, but such cases can't be so trivially solved (and any such gadgets are unlikely to be used with USB3 ports any way). Cc: Felipe Balbi <balbi(a)kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Maciej Żenczykowski <maze(a)google.com> Cc: stable <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20210609024459.1126080-1-zenczykowski@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Xiang Yang <xiangyang3(a)huawei.com> --- drivers/usb/gadget/config.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/usb/gadget/config.c b/drivers/usb/gadget/config.c index 2d115353424c..7275b58ce8cc 100644 --- a/drivers/usb/gadget/config.c +++ b/drivers/usb/gadget/config.c @@ -164,6 +164,14 @@ int usb_assign_descriptors(struct usb_function *f, { struct usb_gadget *g = f->config->cdev->gadget; + /* super-speed-plus descriptor falls back to super-speed one, + * if such a descriptor was provided, thus avoiding a NULL + * pointer dereference if a 5gbps capable gadget is used with + * a 10gbps capable config (device port + cable + host port) + */ + if (!ssp) + ssp = ss; + if (fs) { f->fs_descriptors = usb_copy_descriptors(fs); if (!f->fs_descriptors) -- 2.34.1

2 1

[PATCH OLK-6.6 v2] IMA: Introduce a config to bypass i_version detection for Overlayfs issue
by Xiang Yang 05 Jun '24

05 Jun '24

From: GUO Zihua <guozihua(a)huawei.com> hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I9V12H CVE: NA -------------------------------- IMA detect the backing inode changes through i_version of the backing inode would introduce a performance degrade, so introduce a config to allow users to bypass the i_version detection or not. Signed-off-by: GUO Zihua <guozihua(a)huawei.com> Signed-off-by: Xiang Yang <xiangyang3(a)huawei.com> --- arch/arm64/configs/openeuler_defconfig | 1 + arch/x86/configs/openeuler_defconfig | 1 + security/integrity/ima/Kconfig | 8 ++++++++ security/integrity/ima/ima_main.c | 6 ++++++ 4 files changed, 16 insertions(+) diff --git a/arch/arm64/configs/openeuler_defconfig b/arch/arm64/configs/openeuler_defconfig index 4a368f3a5964..ab1db78f049a 100644 --- a/arch/arm64/configs/openeuler_defconfig +++ b/arch/arm64/configs/openeuler_defconfig @@ -7364,6 +7364,7 @@ CONFIG_IMA_STANDARD_DIGEST_DB_SIZE=y # CONFIG_IMA_CUSTOM_DIGEST_DB_SIZE is not set CONFIG_IMA_DIGEST_DB_MEGABYTES=16 CONFIG_IMA_PARSER_BINARY_PATH="/usr/bin/upload_digest_lists" +# CONFIG_IMA_OVERLAYFS_DETECTION_BYPASS is not set CONFIG_EVM=y # CONFIG_EVM_DEFAULT_HASH_SHA1 is not set CONFIG_EVM_DEFAULT_HASH_SHA256=y diff --git a/arch/x86/configs/openeuler_defconfig b/arch/x86/configs/openeuler_defconfig index 38c191ea24be..0c6fc6018c2c 100644 --- a/arch/x86/configs/openeuler_defconfig +++ b/arch/x86/configs/openeuler_defconfig @@ -8517,6 +8517,7 @@ CONFIG_IMA_STANDARD_DIGEST_DB_SIZE=y # CONFIG_IMA_CUSTOM_DIGEST_DB_SIZE is not set CONFIG_IMA_DIGEST_DB_MEGABYTES=16 CONFIG_IMA_PARSER_BINARY_PATH="/usr/bin/upload_digest_lists" +# CONFIG_IMA_OVERLAYFS_DETECTION_BYPASS is not set CONFIG_EVM=y # CONFIG_EVM_DEFAULT_HASH_SHA1 is not set CONFIG_EVM_DEFAULT_HASH_SHA256=y diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig index 46cb469e06ab..9d920d3ff4f0 100644 --- a/security/integrity/ima/Kconfig +++ b/security/integrity/ima/Kconfig @@ -368,4 +368,12 @@ config IMA_PARSER_BINARY_PATH help This option defines the path of the parser binary. +config IMA_OVERLAYFS_DETECTION_BYPASS + bool "Bypass overlayfs backing inode change detection" + default n + help + This option enables user to bypass the overlayfs backing inode + change detection, while the detection may causes performance + regression. With this config enabled, IMA will not detect inode + change through i_version of the backing inode. If unsure, say N. endif diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c index d29dc604e1d3..9b251ecfa7c2 100644 --- a/security/integrity/ima/ima_main.c +++ b/security/integrity/ima/ima_main.c @@ -282,7 +282,11 @@ static int process_measurement(struct file *file, const struct cred *cred, u32 secid, char *buf, loff_t size, int mask, enum ima_hooks func) { +#ifndef CONFIG_IMA_OVERLAYFS_DETECTION_BYPASS struct inode *backing_inode, *inode = file_inode(file); +#else + struct inode *inode = file_inode(file); +#endif struct integrity_iint_cache *iint = NULL; struct ima_template_desc *template_desc = NULL; char *pathbuf = NULL; @@ -362,6 +366,7 @@ static int process_measurement(struct file *file, const struct cred *cred, iint->measured_pcrs = 0; } +#ifndef CONFIG_IMA_OVERLAYFS_DETECTION_BYPASS /* Detect and re-evaluate changes made to the backing file. */ backing_inode = d_real_inode(file_dentry(file)); if (backing_inode != inode && @@ -374,6 +379,7 @@ static int process_measurement(struct file *file, const struct cred *cred, iint->measured_pcrs = 0; } } +#endif /* Determine if already appraised/measured based on bitmask * (IMA_MEASURE, IMA_MEASURED, IMA_XXXX_APPRAISE, IMA_XXXX_APPRAISED, -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] net: USB: Fix wrong-direction WARNING in plusb.c
by Zhang Zekun 05 Jun '24

05 Jun '24

From: Alan Stern <stern(a)rowland.harvard.edu> from stable-v4.19.273 commit 6f69307f625904feed189008381fd83bd1a35b63 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9R4KG CVE: CVE-2023-52742 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------------------------- commit 811d581194f7412eda97acc03d17fc77824b561f upstream. The syzbot fuzzer detected a bug in the plusb network driver: A zero-length control-OUT transfer was treated as a read instead of a write. In modern kernels this error provokes a WARNING: usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0 WARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411 usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 Modules linked in: CPU: 1 PID: 4645 Comm: dhcpcd Not tainted 6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 ... Call Trace: <TASK> usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153 __usbnet_read_cmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010 usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068 pl_vendor_req drivers/net/usb/plusb.c:60 [inline] pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline] pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85 usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889 __dev_open+0x297/0x4d0 net/core/dev.c:1417 __dev_change_flags+0x587/0x750 net/core/dev.c:8530 dev_change_flags+0x97/0x170 net/core/dev.c:8602 devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147 inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979 sock_do_ioctl+0xcc/0x230 net/socket.c:1169 sock_ioctl+0x1f8/0x680 net/socket.c:1286 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd The fix is to call usbnet_write_cmd() instead of usbnet_read_cmd() and remove the USB_DIR_IN flag. Reported-and-tested-by: syzbot+2a0e7abd24f1eb90ce25(a)syzkaller.appspotmail.com Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Fixes: 090ffa9d0e90 ("[PATCH] USB: usbnet (9/9) module for pl2301/2302 cables") CC: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/00000000000052099f05f3b3e298@google.com/ Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zhang Zekun <zhangzekun11(a)huawei.com> --- drivers/net/usb/plusb.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/usb/plusb.c b/drivers/net/usb/plusb.c index 6fe59373cba9..8bab7306e5a6 100644 --- a/drivers/net/usb/plusb.c +++ b/drivers/net/usb/plusb.c @@ -69,9 +69,7 @@ static inline int pl_vendor_req(struct usbnet *dev, u8 req, u8 val, u8 index) { - return usbnet_read_cmd(dev, req, - USB_DIR_IN | USB_TYPE_VENDOR | - USB_RECIP_DEVICE, + return usbnet_write_cmd(dev, req, USB_TYPE_VENDOR | USB_RECIP_DEVICE, val, index, NULL, 0); } -- 2.17.1

2 1

[PATCH] net: USB: Fix wrong-direction WARNING in plusb.c
by Zhang Zekun 05 Jun '24

05 Jun '24

From: Alan Stern <stern(a)rowland.harvard.edu> from stable-v4.19.273 commit 6f69307f625904feed189008381fd83bd1a35b63 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9R4KG CVE: CVE-2023-52742 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------------------------- commit 811d581194f7412eda97acc03d17fc77824b561f upstream. The syzbot fuzzer detected a bug in the plusb network driver: A zero-length control-OUT transfer was treated as a read instead of a write. In modern kernels this error provokes a WARNING: usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0 WARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411 usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 Modules linked in: CPU: 1 PID: 4645 Comm: dhcpcd Not tainted 6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 ... Call Trace: <TASK> usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153 __usbnet_read_cmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010 usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068 pl_vendor_req drivers/net/usb/plusb.c:60 [inline] pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline] pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85 usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889 __dev_open+0x297/0x4d0 net/core/dev.c:1417 __dev_change_flags+0x587/0x750 net/core/dev.c:8530 dev_change_flags+0x97/0x170 net/core/dev.c:8602 devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147 inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979 sock_do_ioctl+0xcc/0x230 net/socket.c:1169 sock_ioctl+0x1f8/0x680 net/socket.c:1286 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd The fix is to call usbnet_write_cmd() instead of usbnet_read_cmd() and remove the USB_DIR_IN flag. Reported-and-tested-by: syzbot+2a0e7abd24f1eb90ce25(a)syzkaller.appspotmail.com Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Fixes: 090ffa9d0e90 ("[PATCH] USB: usbnet (9/9) module for pl2301/2302 cables") CC: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/00000000000052099f05f3b3e298@google.com/ Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zhang Zekun <zhangzekun11(a)huawei.com> --- drivers/net/usb/plusb.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/usb/plusb.c b/drivers/net/usb/plusb.c index 6fe59373cba9..8bab7306e5a6 100644 --- a/drivers/net/usb/plusb.c +++ b/drivers/net/usb/plusb.c @@ -69,9 +69,7 @@ static inline int pl_vendor_req(struct usbnet *dev, u8 req, u8 val, u8 index) { - return usbnet_read_cmd(dev, req, - USB_DIR_IN | USB_TYPE_VENDOR | - USB_RECIP_DEVICE, + return usbnet_write_cmd(dev, req, USB_TYPE_VENDOR | USB_RECIP_DEVICE, val, index, NULL, 0); } -- 2.17.1

1 0

[PATCH openEuler-22.03-LTS-SP1] wifi: cfg80211: check A-MSDU format more carefully
by Dong Chenchen 05 Jun '24

05 Jun '24

From: Johannes Berg <johannes.berg(a)intel.com> mainline inclusion from mainline-v6.9-rc1 commit 9ad7974856926129f190ffbe3beea78460b3b7cc category: bugfix bugzilla: 190054, https://gitee.com/src-openeuler/kernel/issues/I9QGJD CVE: CVE-2024-35937 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If it looks like there's another subframe in the A-MSDU but the header isn't fully there, we can end up reading data out of bounds, only to discard later. Make this a bit more careful and check if the subframe header can even be present. Reported-by: syzbot+d050d437fe47d479d210(a)syzkaller.appspotmail.com Link: https://msgid.link/20240226203405.a731e2c95e38.I82ce7d8c0cc8970ce29d0a39fdc… Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Conflicts: net/wireless/util.c [ieee80211_is_valid_amsdu() isnt implemented in the current version for commit 6e4c0d0460bd not merged. commit 9f718554e7ea and 986e43b19ae9 wasnt merged, which lead to context conflicts] Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/wireless/util.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/net/wireless/util.c b/net/wireless/util.c index 4b32e85c2d9a..5177fd63b1b8 100644 --- a/net/wireless/util.c +++ b/net/wireless/util.c @@ -751,24 +751,27 @@ void ieee80211_amsdu_to_8023s(struct sk_buff *skb, struct sk_buff_head *list, struct sk_buff *frame = NULL; u16 ethertype; u8 *payload; - int offset = 0, remaining; + int offset = 0; struct ethhdr eth; bool reuse_frag = skb->head_frag && !skb_has_frag_list(skb); bool reuse_skb = false; bool last = false; while (!last) { + int remaining = skb->len - offset; unsigned int subframe_len; int len; u8 padding; + if (sizeof(eth) > remaining) + goto purge; + skb_copy_bits(skb, offset, &eth, sizeof(eth)); len = ntohs(eth.h_proto); subframe_len = sizeof(struct ethhdr) + len; padding = (4 - subframe_len) & 0x3; /* the last MSDU has no padding */ - remaining = skb->len - offset; if (subframe_len > remaining) goto purge; /* mitigate A-MSDU aggregation injection attacks */ -- 2.25.1

2 1

2024

2023

2022

2021

2020

2019

Kernel