- Kernel - mailweb.openeuler.org

[openeuler:OLK-6.6 2676/3767] rdtgroup.c:undefined reference to `lockdep_is_cpus_held'
by kernel test robot 02 Mar '24

02 Mar '24

Hi James, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 236cb940335e3542c9d5ac16b5d8546a0cbbdfc1 commit: c054efea286659a6504fdeafc0a611c6a3b124cc [2676/3767] x86/resctrl: Claim get_domain_from_cpu() for resctrl config: x86_64-buildonly-randconfig-004-20240301 (https://download.01.org/0day-ci/archive/20240302/202403021655.4zz3RhBO-lkp@…) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240302/202403021655.4zz3RhBO-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202403021655.4zz3RhBO-lkp@intel.com/ All errors (new ones prefixed by >>): ld: arch/x86/kernel/cpu/resctrl/core.o: in function `rdt_ctrl_update': core.c:(.text+0x2561): undefined reference to `lockdep_is_cpus_held' ld: arch/x86/kernel/cpu/resctrl/rdtgroup.o: in function `resctrl_offline_cpu': >> rdtgroup.c:(.text+0x12301): undefined reference to `lockdep_is_cpus_held' ld: arch/x86/kernel/cpu/resctrl/monitor.o: in function `update_mba_bw': monitor.c:(.text+0x31e): undefined reference to `lockdep_is_cpus_held' -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-1.0-LTS] Input: powermate - fix use-after-free in powermate_config_complete
by Xiang Yang 02 Mar '24

02 Mar '24

From: Javier Carrasco <javier.carrasco.cruz(a)gmail.com> stable inclusion from stable-v4.19.297 commit 67cace72606baf1758fd60feb358f4c6be92e1cc category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I94PA7 CVE: CVE-2023-52475 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ----------------------------------------------------- commit 5c15c60e7be615f05a45cd905093a54b11f461bc upstream. syzbot has found a use-after-free bug [1] in the powermate driver. This happens when the device is disconnected, which leads to a memory free from the powermate_device struct. When an asynchronous control message completes after the kfree and its callback is invoked, the lock does not exist anymore and hence the bug. Use usb_kill_urb() on pm->config to cancel any in-progress requests upon device disconnection. [1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e Signed-off-by: Javier Carrasco <javier.carrasco.cruz(a)gmail.com> Reported-by: syzbot+0434ac83f907a1dbdd1e(a)syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20230916-topic-powermate_use_after_free-v3-1-6441… Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Xiang Yang <xiangyang3(a)huawei.com> --- drivers/input/misc/powermate.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/input/misc/powermate.c b/drivers/input/misc/powermate.c index e8de3aaf9f63..14f48e10f589 100644 --- a/drivers/input/misc/powermate.c +++ b/drivers/input/misc/powermate.c @@ -424,6 +424,7 @@ static void powermate_disconnect(struct usb_interface *intf) pm->requires_update = 0; usb_kill_urb(pm->irq); input_unregister_device(pm->input); + usb_kill_urb(pm->config); usb_free_urb(pm->irq); usb_free_urb(pm->config); powermate_free_buffers(interface_to_usbdev(intf), pm); -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP2] ext4: regenerate buddy after block freeing failed if under fc replay
by Baokun Li 02 Mar '24

02 Mar '24

mainline inclusion from mainline-v6.8-rc3 commit c9b528c35795b711331ed36dc3dbee90d5812d4e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I93HD9 CVE: CVE-2024-26601 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- This mostly reverts commit 6bd97bf273bd ("ext4: remove redundant mb_regenerate_buddy()") and reintroduces mb_regenerate_buddy(). Based on code in mb_free_blocks(), fast commit replay can end up marking as free blocks that are already marked as such. This causes corruption of the buddy bitmap so we need to regenerate it in that case. Reported-by: Jan Kara <jack(a)suse.cz> Fixes: 6bd97bf273bd ("ext4: remove redundant mb_regenerate_buddy()") Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Link: https://lore.kernel.org/r/20240104142040.2835097-4-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Conflicts: fs/ext4/mballoc.c Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/ext4/mballoc.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c index 929fc424d68a..cdb443932e3b 100644 --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -822,6 +822,24 @@ void ext4_mb_generate_buddy(struct super_block *sb, atomic64_add(period, &sbi->s_mb_generation_time); } +static void mb_regenerate_buddy(struct ext4_buddy *e4b) +{ + int count; + int order = 1; + void *buddy; + + while ((buddy = mb_find_buddy(e4b, order++, &count))) + ext4_set_bits(buddy, 0, count); + + e4b->bd_info->bb_fragments = 0; + memset(e4b->bd_info->bb_counters, 0, + sizeof(*e4b->bd_info->bb_counters) * + (e4b->bd_sb->s_blocksize_bits + 2)); + + ext4_mb_generate_buddy(e4b->bd_sb, e4b->bd_buddy, + e4b->bd_bitmap, e4b->bd_group, e4b->bd_info); +} + /* The buddy information is attached the buddy cache inode * for convenience. The information regarding each group * is loaded via ext4_mb_load_buddy. The information involve @@ -1504,6 +1522,8 @@ static void mb_free_blocks(struct inode *inode, struct ext4_buddy *e4b, ext4_mark_group_bitmap_corrupted( sb, e4b->bd_group, EXT4_GROUP_INFO_BBITMAP_CORRUPT); + } else { + mb_regenerate_buddy(e4b); } goto done; } -- 2.31.1

2 1

[openeuler:OLK-6.6 780/3767] arch/loongarch/kernel/dma.c:37:42: sparse: sparse: incorrect type in argument 1 (different address spaces)
by kernel test robot 02 Mar '24

02 Mar '24

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: fbcd4a3032a53350f6d182c9daeaa4c46e65d964 commit: 90d2bbc1ade2216bda17fb582a1aaabf7567478f [780/3767] LoongArch: use arch specific phys_to_dma config: loongarch-randconfig-r112-20240302 (https://download.01.org/0day-ci/archive/20240302/202403021652.crccT6al-lkp@…) compiler: loongarch64-linux-gcc (GCC) 13.2.0 reproduce: (https://download.01.org/0day-ci/archive/20240302/202403021652.crccT6al-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202403021652.crccT6al-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) >> arch/loongarch/kernel/dma.c:37:42: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] __iomem *addr @@ got void volatile * @@ arch/loongarch/kernel/dma.c:37:42: sparse: expected void const volatile [noderef] __iomem *addr arch/loongarch/kernel/dma.c:37:42: sparse: got void volatile * vim +37 arch/loongarch/kernel/dma.c 29 30 void acpi_arch_dma_setup(struct device *dev) 31 { 32 int ret; 33 u64 mask, end = 0; 34 const struct bus_dma_region *map = NULL; 35 36 if (node_id_offset == 0) { > 37 node_id_offset = ((readl(LS7A_DMA_CFG) & LS7A_DMA_NODE_MASK) >> LS7A_DMA_NODE_SHF); 38 node_id_offset += 36; 39 } 40 41 ret = acpi_dma_get_range(dev, &map); 42 if (!ret && map) { 43 const struct bus_dma_region *r = map; 44 45 for (end = 0; r->size; r++) { 46 if (r->dma_start + r->size - 1 > end) 47 end = r->dma_start + r->size - 1; 48 } 49 50 mask = DMA_BIT_MASK(ilog2(end) + 1); 51 dev->bus_dma_limit = end; 52 dev->dma_range_map = map; 53 dev->coherent_dma_mask = min(dev->coherent_dma_mask, mask); 54 *dev->dma_mask = min(*dev->dma_mask, mask); 55 } 56 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-1.0-LTS] i2c: cadence: fix reference leak when pm_runtime_get_sync fails
by Jinjiang Tu 02 Mar '24

02 Mar '24

From: Qinglang Miao <miaoqinglang(a)huawei.com> mainline inclusion from mainline-v5.13-rc1 commit 23ceb8462dc6f4b4decdb5536a7e5fc477cdf0b6 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I94JHY CVE: CVE-2020-36784 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- The PM reference count is not expected to be incremented on return in functions cdns_i2c_master_xfer and cdns_reg_slave. However, pm_runtime_get_sync will increment pm usage counter even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. Fixes: 7fa32329ca03 ("i2c: cadence: Move to sensible power management") Reported-by: Hulk Robot <hulkci(a)huawei.com> Signed-off-by: Qinglang Miao <miaoqinglang(a)huawei.com> Signed-off-by: Wolfram Sang <wsa(a)kernel.org> Conflicts: drivers/i2c/busses/i2c-cadence.c Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- drivers/i2c/busses/i2c-cadence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c index d917cefc5a19..f64c7f8b924e 100644 --- a/drivers/i2c/busses/i2c-cadence.c +++ b/drivers/i2c/busses/i2c-cadence.c @@ -578,7 +578,7 @@ static int cdns_i2c_master_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, struct cdns_i2c *id = adap->algo_data; bool hold_quirk; - ret = pm_runtime_get_sync(id->dev); + ret = pm_runtime_resume_and_get(id->dev); if (ret < 0) return ret; /* Check if the bus is free */ -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] usb: dwc3: core: Do core softreset when switch mode
by Zhang Xiaoxu 02 Mar '24

02 Mar '24

From: Yu Chen <chenyu56(a)huawei.com> mainline inclusion from mainline-v5.13-rc1 commit f88359e1588b85cf0e8209ab7d6620085f3441d9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I949BN CVE: CVE-2021-46941 --------------------------- From: John Stultz <john.stultz(a)linaro.org> According to the programming guide, to switch mode for DRD controller, the driver needs to do the following. To switch from device to host: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(host mode) 3. Reset the host with USBCMD.HCRESET 4. Then follow up with the initializing host registers sequence To switch from host to device: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(device mode) 3. Reset the device with DCTL.CSftRst 4. Then follow up with the initializing registers sequence Currently we're missing step 1) to do GCTL.CoreSoftReset and step 3) of switching from host to device. John Stult reported a lockup issue seen with HiKey960 platform without these steps[1]. Similar issue is observed with Ferry's testing platform[2]. So, apply the required steps along with some fixes to Yu Chen's and John Stultz's version. The main fixes to their versions are the missing wait for clocks synchronization before clearing GCTL.CoreSoftReset and only apply DCTL.CSftRst when switching from host to device. [1] https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro… [2] https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7-9cd4-0695-64fc927e01f1@gmai… Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly") Cc: Andy Shevchenko <andy.shevchenko(a)gmail.com> Cc: Ferry Toth <fntoth(a)gmail.com> Cc: Wesley Cheng <wcheng(a)codeaurora.org> Cc: <stable(a)vger.kernel.org> Tested-by: John Stultz <john.stultz(a)linaro.org> Tested-by: Wesley Cheng <wcheng(a)codeaurora.org> Signed-off-by: Yu Chen <chenyu56(a)huawei.com> Signed-off-by: John Stultz <john.stultz(a)linaro.org> Signed-off-by: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Link: https://lore.kernel.org/r/374440f8dcd4f06c02c2caf4b1efde86774e02d9.16185216… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5(a)huawei.com> Conflicts: drivers/usb/dwc3/core.c --- drivers/usb/dwc3/core.c | 37 +++++++++++++++++++++++++++++++++---- drivers/usb/dwc3/core.h | 5 +++++ 2 files changed, 38 insertions(+), 4 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index f52fcbc5c971..3f605ca8a8c3 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -111,26 +111,31 @@ void dwc3_set_prtcap(struct dwc3 *dwc, u32 mode) dwc->current_dr_role = mode; } +static int dwc3_core_soft_reset(struct dwc3 *dwc); + static void __dwc3_set_mode(struct work_struct *work) { struct dwc3 *dwc = work_to_dwc(work); unsigned long flags; int ret; + u32 reg; + + mutex_lock(&dwc->mutex); if (dwc->dr_mode != USB_DR_MODE_OTG) - return; + goto out; if (dwc->current_dr_role == DWC3_GCTL_PRTCAP_OTG) dwc3_otg_update(dwc, 0); if (!dwc->desired_dr_role) - return; + goto out; if (dwc->desired_dr_role == dwc->current_dr_role) - return; + goto out; if (dwc->desired_dr_role == DWC3_GCTL_PRTCAP_OTG && dwc->edev) - return; + goto out; switch (dwc->current_dr_role) { case DWC3_GCTL_PRTCAP_HOST: @@ -151,6 +156,25 @@ static void __dwc3_set_mode(struct work_struct *work) break; } + /* For DRD host or device mode only */ + if (dwc->desired_dr_role != DWC3_GCTL_PRTCAP_OTG) { + reg = dwc3_readl(dwc->regs, DWC3_GCTL); + reg |= DWC3_GCTL_CORESOFTRESET; + dwc3_writel(dwc->regs, DWC3_GCTL, reg); + + /* + * Wait for internal clocks to synchronized. DWC_usb31 and + * DWC_usb32 may need at least 50ms (less for DWC_usb3). To + * keep it consistent across different IPs, let's wait up to + * 100ms before clearing GCTL.CORESOFTRESET. + */ + msleep(100); + + reg = dwc3_readl(dwc->regs, DWC3_GCTL); + reg &= ~DWC3_GCTL_CORESOFTRESET; + dwc3_writel(dwc->regs, DWC3_GCTL, reg); + } + spin_lock_irqsave(&dwc->lock, flags); dwc3_set_prtcap(dwc, dwc->desired_dr_role); @@ -171,6 +195,8 @@ static void __dwc3_set_mode(struct work_struct *work) } break; case DWC3_GCTL_PRTCAP_DEVICE: + dwc3_core_soft_reset(dwc); + dwc3_event_buffers_setup(dwc); if (dwc->usb2_phy) @@ -190,6 +216,8 @@ static void __dwc3_set_mode(struct work_struct *work) break; } +out: + mutex_unlock(&dwc->mutex); } void dwc3_set_mode(struct dwc3 *dwc, u32 mode) @@ -1453,6 +1481,7 @@ static int dwc3_probe(struct platform_device *pdev) dwc3_cache_hwparams(dwc); spin_lock_init(&dwc->lock); + mutex_init(&dwc->mutex); pm_runtime_set_active(dev); pm_runtime_use_autosuspend(dev); diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h index 131028501752..a5d3004ae388 100644 --- a/drivers/usb/dwc3/core.h +++ b/drivers/usb/dwc3/core.h @@ -13,6 +13,7 @@ #include <linux/device.h> #include <linux/spinlock.h> +#include <linux/mutex.h> #include <linux/ioport.h> #include <linux/list.h> #include <linux/bitops.h> @@ -896,6 +897,7 @@ struct dwc3_scratchpad_array { * @scratch_addr: dma address of scratchbuf * @ep0_in_setup: one control transfer is completed and enter setup phase * @lock: for synchronizing + * @mutex: for mode switching * @dev: pointer to our struct device * @sysdev: pointer to the DMA-capable device * @xhci: pointer to our xHCI child @@ -1017,6 +1019,9 @@ struct dwc3 { /* device lock */ spinlock_t lock; + /* mode switching lock */ + struct mutex mutex; + struct device *dev; struct device *sysdev; -- 2.34.1

2 1

[PATCH OLK-5.10] ext4: regenerate buddy after block freeing failed if under fc replay
by Baokun Li 02 Mar '24

02 Mar '24

mainline inclusion from mainline-v6.8-rc3 commit c9b528c35795b711331ed36dc3dbee90d5812d4e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I93HD9 CVE: CVE-2024-26601 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- This mostly reverts commit 6bd97bf273bd ("ext4: remove redundant mb_regenerate_buddy()") and reintroduces mb_regenerate_buddy(). Based on code in mb_free_blocks(), fast commit replay can end up marking as free blocks that are already marked as such. This causes corruption of the buddy bitmap so we need to regenerate it in that case. Reported-by: Jan Kara <jack(a)suse.cz> Fixes: 6bd97bf273bd ("ext4: remove redundant mb_regenerate_buddy()") Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Link: https://lore.kernel.org/r/20240104142040.2835097-4-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Conflicts: fs/ext4/mballoc.c Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/ext4/mballoc.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c index bc25bdbcb01e..5d68204070e4 100644 --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -822,6 +822,24 @@ void ext4_mb_generate_buddy(struct super_block *sb, atomic64_add(period, &sbi->s_mb_generation_time); } +static void mb_regenerate_buddy(struct ext4_buddy *e4b) +{ + int count; + int order = 1; + void *buddy; + + while ((buddy = mb_find_buddy(e4b, order++, &count))) + ext4_set_bits(buddy, 0, count); + + e4b->bd_info->bb_fragments = 0; + memset(e4b->bd_info->bb_counters, 0, + sizeof(*e4b->bd_info->bb_counters) * + (e4b->bd_sb->s_blocksize_bits + 2)); + + ext4_mb_generate_buddy(e4b->bd_sb, e4b->bd_buddy, + e4b->bd_bitmap, e4b->bd_group, e4b->bd_info); +} + /* The buddy information is attached the buddy cache inode * for convenience. The information regarding each group * is loaded via ext4_mb_load_buddy. The information involve @@ -1504,6 +1522,8 @@ static void mb_free_blocks(struct inode *inode, struct ext4_buddy *e4b, ext4_mark_group_bitmap_corrupted( sb, e4b->bd_group, EXT4_GROUP_INFO_BBITMAP_CORRUPT); + } else { + mb_regenerate_buddy(e4b); } goto done; } -- 2.31.1

2 1

[PATCH openEuler-1.0-LTS] apparmor: avoid crash when parsed profile name is empty
by Xiang Yang 02 Mar '24

02 Mar '24

From: Fedor Pchelkin <pchelkin(a)ispras.ru> stable inclusion from stable-v4.19.306 commit 9286ee97aa4803d99185768735011d0d65827c9e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I932W7 CVE: CVE-2023-52443 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ----------------------------------------------------- [ Upstream commit 55a8210c9e7d21ff2644809699765796d4bfb200 ] When processing a packed profile in unpack_profile() described like "profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...}" a string ":samba-dcerpcd" is unpacked as a fully-qualified name and then passed to aa_splitn_fqname(). aa_splitn_fqname() treats ":samba-dcerpcd" as only containing a namespace. Thus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Later aa_alloc_profile() crashes as the new profile name is NULL now. general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 6 PID: 1657 Comm: apparmor_parser Not tainted 6.7.0-rc2-dirty #16 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 RIP: 0010:strlen+0x1e/0xa0 Call Trace: <TASK> ? strlen+0x1e/0xa0 aa_policy_init+0x1bb/0x230 aa_alloc_profile+0xb1/0x480 unpack_profile+0x3bc/0x4960 aa_unpack+0x309/0x15e0 aa_replace_profiles+0x213/0x33c0 policy_update+0x261/0x370 profile_replace+0x20e/0x2a0 vfs_write+0x2af/0xe00 ksys_write+0x126/0x250 do_syscall_64+0x46/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 </TASK> ---[ end trace 0000000000000000 ]--- RIP: 0010:strlen+0x1e/0xa0 It seems such behaviour of aa_splitn_fqname() is expected and checked in other places where it is called (e.g. aa_remove_profiles). Well, there is an explicit comment "a ns name without a following profile is allowed" inside. AFAICS, nothing can prevent unpacked "name" to be in form like ":samba-dcerpcd" - it is passed from userspace. Deny the whole profile set replacement in such case and inform user with EPROTO and an explaining message. Found by Linux Verification Center (linuxtesting.org) Fixes: 04dc715e24d0 ("apparmor: audit policy ns specified in policy load") Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> Signed-off-by: John Johansen <john.johansen(a)canonical.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Xiang Yang <xiangyang3(a)huawei.com> --- security/apparmor/policy_unpack.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/security/apparmor/policy_unpack.c b/security/apparmor/policy_unpack.c index 612f737cee83..36bf9534acf0 100644 --- a/security/apparmor/policy_unpack.c +++ b/security/apparmor/policy_unpack.c @@ -635,6 +635,10 @@ static struct aa_profile *unpack_profile(struct aa_ext *e, char **ns_name) tmpname = aa_splitn_fqname(name, strlen(name), &tmpns, &ns_len); if (tmpns) { + if (!tmpname) { + info = "empty profile name"; + goto fail; + } *ns_name = kstrndup(tmpns, ns_len, GFP_KERNEL); if (!*ns_name) { info = "out of memory"; -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] hfsplus: prevent corruption in shrinking truncate
by Baokun Li 02 Mar '24

02 Mar '24

From: Jouni Roivas <jouni.roivas(a)tuxera.com> stable inclusion from stable-v4.19.191 commit 52dde855663e5db824af51db39b5757d2ef3e28a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I94JCO CVE: CVE-2021-46989 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit c3187cf32216313fb316084efac4dab3a8459b1d upstream. I believe there are some issues introduced by commit 31651c607151 ("hfsplus: avoid deadlock on file truncation") HFS+ has extent records which always contains 8 extents. In case the first extent record in catalog file gets full, new ones are allocated from extents overflow file. In case shrinking truncate happens to middle of an extent record which locates in extents overflow file, the logic in hfsplus_file_truncate() was changed so that call to hfs_brec_remove() is not guarded any more. Right action would be just freeing the extents that exceed the new size inside extent record by calling hfsplus_free_extents(), and then check if the whole extent record should be removed. However since the guard (blk_cnt > start) is now after the call to hfs_brec_remove(), this has unfortunate effect that the last matching extent record is removed unconditionally. To reproduce this issue, create a file which has at least 10 extents, and then perform shrinking truncate into middle of the last extent record, so that the number of remaining extents is not under or divisible by 8. This causes the last extent record (8 extents) to be removed totally instead of truncating into middle of it. Thus this causes corruption, and lost data. Fix for this is simply checking if the new truncated end is below the start of this extent record, making it safe to remove the full extent record. However call to hfs_brec_remove() can't be moved to it's previous place since we're dropping ->tree_lock and it can cause a race condition and the cached info being invalidated possibly corrupting the node data. Another issue is related to this one. When entering into the block (blk_cnt > start) we are not holding the ->tree_lock. We break out from the loop not holding the lock, but hfs_find_exit() does unlock it. Not sure if it's possible for someone else to take the lock under our feet, but it can cause hard to debug errors and premature unlocking. Even if there's no real risk of it, the locking should still always be kept in balance. Thus taking the lock now just before the check. Link: https://lkml.kernel.org/r/20210429165139.3082828-1-jouni.roivas@tuxera.com Fixes: 31651c607151f ("hfsplus: avoid deadlock on file truncation") Signed-off-by: Jouni Roivas <jouni.roivas(a)tuxera.com> Reviewed-by: Anton Altaparmakov <anton(a)tuxera.com> Cc: Anatoly Trosinenko <anatoly.trosinenko(a)gmail.com> Cc: Viacheslav Dubeyko <slava(a)dubeyko.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/hfsplus/extents.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/fs/hfsplus/extents.c b/fs/hfsplus/extents.c index a930ddd15681..7054a542689f 100644 --- a/fs/hfsplus/extents.c +++ b/fs/hfsplus/extents.c @@ -598,13 +598,15 @@ void hfsplus_file_truncate(struct inode *inode) res = __hfsplus_ext_cache_extent(&fd, inode, alloc_cnt); if (res) break; - hfs_brec_remove(&fd); - mutex_unlock(&fd.tree->tree_lock); start = hip->cached_start; + if (blk_cnt <= start) + hfs_brec_remove(&fd); + mutex_unlock(&fd.tree->tree_lock); hfsplus_free_extents(sb, hip->cached_extents, alloc_cnt - start, alloc_cnt - blk_cnt); hfsplus_dump_extent(hip->cached_extents); + mutex_lock(&fd.tree->tree_lock); if (blk_cnt > start) { hip->extent_state |= HFSPLUS_EXT_DIRTY; break; @@ -612,7 +614,6 @@ void hfsplus_file_truncate(struct inode *inode) alloc_cnt = start; hip->cached_start = hip->cached_blocks = 0; hip->extent_state &= ~(HFSPLUS_EXT_DIRTY | HFSPLUS_EXT_NEW); - mutex_lock(&fd.tree->tree_lock); } hfs_find_exit(&fd); -- 2.31.1

2 1

[openeuler:OLK-6.6 3630/3767] include/linux/ras.h:45:1: error: return type defaults to 'int'
by kernel test robot 02 Mar '24

02 Mar '24

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 236cb940335e3542c9d5ac16b5d8546a0cbbdfc1 commit: fa75636857993e25030c3db31444d2aa01d5d9de [3630/3767] RAS: Report ARM processor information to userspace config: x86_64-defconfig (https://download.01.org/0day-ci/archive/20240302/202403021440.BIb46Slr-lkp@…) compiler: gcc-11 (Debian 11.3.0-12) 11.3.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240302/202403021440.BIb46Slr-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202403021440.BIb46Slr-lkp@intel.com/ Note: the openeuler/OLK-6.6 HEAD 236cb940335e3542c9d5ac16b5d8546a0cbbdfc1 builds fine. It only hurts bisectability. All errors (new ones prefixed by >>): In file included from arch/x86/kernel/cpu/mce/core.c:36: >> include/linux/ras.h:45:1: error: return type defaults to 'int' [-Werror=implicit-int] 45 | log_arm_hw_error(struct cper_sec_proc_arm *err) { return; } | ^~~~~~~~~~~~~~~~ include/linux/ras.h:45:1: warning: no previous prototype for 'log_arm_hw_error' [-Wmissing-prototypes] include/linux/ras.h: In function 'log_arm_hw_error': include/linux/ras.h:45:51: warning: 'return' with no value, in function returning non-void [-Wreturn-type] 45 | log_arm_hw_error(struct cper_sec_proc_arm *err) { return; } | ^~~~~~ include/linux/ras.h:45:1: note: declared here 45 | log_arm_hw_error(struct cper_sec_proc_arm *err) { return; } | ^~~~~~~~~~~~~~~~ cc1: some warnings being treated as errors vim +/int +45 include/linux/ras.h fa75636857993e Shengwei Luo 2022-02-23 40 fa75636857993e Shengwei Luo 2022-02-23 41 #ifdef CONFIG_RAS_ARM_EVENT_INFO 0607512d0a8d7f Arnd Bergmann 2017-06-27 42 static inline void fa75636857993e Shengwei Luo 2022-02-23 43 log_arm_hw_error(struct cper_sec_proc_arm *err, const u8 sev) { return; } fa75636857993e Shengwei Luo 2022-02-23 44 #else 0607512d0a8d7f Arnd Bergmann 2017-06-27 @45 log_arm_hw_error(struct cper_sec_proc_arm *err) { return; } 297b64c74385fc Tyler Baicar 2017-06-21 46 #endif 297b64c74385fc Tyler Baicar 2017-06-21 47 :::::: The code at line 45 was first introduced by commit :::::: 0607512d0a8d7fac86667466b884095e04b10a59 ras: mark stub functions as 'inline' :::::: TO: Arnd Bergmann <arnd(a)arndb.de> :::::: CC: Will Deacon <will.deacon(a)arm.com> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0