June 2024 - Kernel - mailweb.openeuler.org

[PATCH openEuler-22.03-LTS-SP1] fs/ntfs3: Use variable length array instead of fixed size
by Long Li 24 Jun '24

24 Jun '24

From: Konstantin Komarov <almaz.alexandrovich(a)paragon-software.com> stable inclusion from stable-v5.15.160 commit a2de301d90b782ac5d7a5fe32995caaee9ab3a0f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D5A CVE: CVE-2024-38623 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… -------------------------------- [ Upstream commit 1997cdc3e727526aa5d84b32f7cbb3f56459b7ef ] Should fix smatch warning: ntfs_set_label() error: __builtin_memcpy() 'uni->name' too small (20 vs 256) Fixes: 4534a70b7056f ("fs/ntfs3: Add headers and misc files") Reported-by: kernel test robot <lkp(a)intel.com> Reported-by: Dan Carpenter <dan.carpenter(a)linaro.org> Closes: https://lore.kernel.org/r/202401091421.3RJ24Mn3-lkp@intel.com/ Signed-off-by: Konstantin Komarov <almaz.alexandrovich(a)paragon-software.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/ntfs3/ntfs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ntfs3/ntfs.h b/fs/ntfs3/ntfs.h index 9cc396b117bf..2e2c6126bbf4 100644 --- a/fs/ntfs3/ntfs.h +++ b/fs/ntfs3/ntfs.h @@ -59,7 +59,7 @@ struct GUID { struct cpu_str { u8 len; u8 unused; - u16 name[10]; + u16 name[]; }; struct le_str { -- 2.39.2

2 1

[PATCH OLK-5.10] fs/ntfs3: Use variable length array instead of fixed size
by Long Li 24 Jun '24

24 Jun '24

From: Konstantin Komarov <almaz.alexandrovich(a)paragon-software.com> stable inclusion from stable-v5.15.160 commit a2de301d90b782ac5d7a5fe32995caaee9ab3a0f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D5A CVE: CVE-2024-38623 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… -------------------------------- [ Upstream commit 1997cdc3e727526aa5d84b32f7cbb3f56459b7ef ] Should fix smatch warning: ntfs_set_label() error: __builtin_memcpy() 'uni->name' too small (20 vs 256) Fixes: 4534a70b7056f ("fs/ntfs3: Add headers and misc files") Reported-by: kernel test robot <lkp(a)intel.com> Reported-by: Dan Carpenter <dan.carpenter(a)linaro.org> Closes: https://lore.kernel.org/r/202401091421.3RJ24Mn3-lkp@intel.com/ Signed-off-by: Konstantin Komarov <almaz.alexandrovich(a)paragon-software.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/ntfs3/ntfs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ntfs3/ntfs.h b/fs/ntfs3/ntfs.h index 9cc396b117bf..2e2c6126bbf4 100644 --- a/fs/ntfs3/ntfs.h +++ b/fs/ntfs3/ntfs.h @@ -59,7 +59,7 @@ struct GUID { struct cpu_str { u8 len; u8 unused; - u16 name[10]; + u16 name[]; }; struct le_str { -- 2.39.2

2 1

[PATCH OLK-5.10] [Backport] macintosh/via-macii: Fix "BUG: sleeping function called from invalid context"
by felix 24 Jun '24

24 Jun '24

From: Finn Thain <fthain(a)linux-m68k.org> stable inclusion from stable-v5.10.219 commit 280619bbdeac186fb320fab3d61122d2a085def8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SHU CVE: CVE-2024-38607 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit d301a71c76ee4c384b4e03cdc320a55f5cf1df05 ] The via-macii ADB driver calls request_irq() after disabling hard interrupts. But disabling interrupts isn't necessary here because the VIA shift register interrupt was masked during VIA1 initialization. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Finn Thain <fthain(a)linux-m68k.org> Reviewed-by: Geert Uytterhoeven <geert(a)linux-m68k.org> Link: https://lore.kernel.org/r/419fcc09d0e563b425c419053d02236b044d86b0.17102984… Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Felix Fu <fuzhen5(a)huawei.com> --- drivers/macintosh/via-macii.c | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/drivers/macintosh/via-macii.c b/drivers/macintosh/via-macii.c index 060e03f2264b..6adb34d1e381 100644 --- a/drivers/macintosh/via-macii.c +++ b/drivers/macintosh/via-macii.c @@ -142,24 +142,19 @@ static int macii_probe(void) /* Initialize the driver */ static int macii_init(void) { - unsigned long flags; int err; - local_irq_save(flags); - err = macii_init_via(); if (err) - goto out; + return err; err = request_irq(IRQ_MAC_ADB, macii_interrupt, 0, "ADB", macii_interrupt); if (err) - goto out; + return err; macii_state = idle; -out: - local_irq_restore(flags); - return err; + return 0; } /* initialize the hardware */ -- 2.34.1

2 1

[PATCH OLK-6.6] [Backport] macintosh/via-macii: Fix "BUG: sleeping function called from invalid context"
by felix 24 Jun '24

24 Jun '24

From: Finn Thain <fthain(a)linux-m68k.org> stable inclusion from stable-v6.6.33 commit d43a8c7ec0841e0ff91a968770aeca83f0fd4c56 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SHU CVE: CVE-2024-38607 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit d301a71c76ee4c384b4e03cdc320a55f5cf1df05 ] The via-macii ADB driver calls request_irq() after disabling hard interrupts. But disabling interrupts isn't necessary here because the VIA shift register interrupt was masked during VIA1 initialization. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Finn Thain <fthain(a)linux-m68k.org> Reviewed-by: Geert Uytterhoeven <geert(a)linux-m68k.org> Link: https://lore.kernel.org/r/419fcc09d0e563b425c419053d02236b044d86b0.17102984… Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Felix Fu <fuzhen5(a)huawei.com> --- drivers/macintosh/via-macii.c | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/drivers/macintosh/via-macii.c b/drivers/macintosh/via-macii.c index db9270da5b8e..b6ddf1d47cb4 100644 --- a/drivers/macintosh/via-macii.c +++ b/drivers/macintosh/via-macii.c @@ -140,24 +140,19 @@ static int macii_probe(void) /* Initialize the driver */ static int macii_init(void) { - unsigned long flags; int err; - local_irq_save(flags); - err = macii_init_via(); if (err) - goto out; + return err; err = request_irq(IRQ_MAC_ADB, macii_interrupt, 0, "ADB", macii_interrupt); if (err) - goto out; + return err; macii_state = idle; -out: - local_irq_restore(flags); - return err; + return 0; } /* initialize the hardware */ -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] serial: max3100: Lock port->lock when calling uart_handle_cts_change()
by Yi Yang 24 Jun '24

24 Jun '24

From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> stable inclusion from stable-v5.10.219 commit cc121e3722a0a2c8f716ef991e5425b180a5fb94 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D3L CVE: CVE-2024-38634 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 77ab53371a2066fdf9b895246505f5ef5a4b5d47 ] uart_handle_cts_change() has to be called with port lock taken, Since we run it in a separate work, the lock may not be taken at the time of running. Make sure that it's taken by explicitly doing that. Without it we got a splat: WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0 ... Workqueue: max3100-0 max3100_work [max3100] RIP: 0010:uart_handle_cts_change+0xa6/0xb0 ... max3100_handlerx+0xc5/0x110 [max3100] max3100_work+0x12a/0x340 [max3100] Fixes: 7831d56b0a35 ("tty: MAX3100") Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Link: https://lore.kernel.org/r/20240402195306.269276-2-andriy.shevchenko@linux.i… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- drivers/tty/serial/max3100.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/drivers/tty/serial/max3100.c b/drivers/tty/serial/max3100.c index 371569a0fd00..915d7753eec2 100644 --- a/drivers/tty/serial/max3100.c +++ b/drivers/tty/serial/max3100.c @@ -213,7 +213,7 @@ static int max3100_sr(struct max3100_port *s, u16 tx, u16 *rx) return 0; } -static int max3100_handlerx(struct max3100_port *s, u16 rx) +static int max3100_handlerx_unlocked(struct max3100_port *s, u16 rx) { unsigned int ch, flg, status = 0; int ret = 0, cts; @@ -253,6 +253,17 @@ static int max3100_handlerx(struct max3100_port *s, u16 rx) return ret; } +static int max3100_handlerx(struct max3100_port *s, u16 rx) +{ + unsigned long flags; + int ret; + + uart_port_lock_irqsave(&s->port, &flags); + ret = max3100_handlerx_unlocked(s, rx); + uart_port_unlock_irqrestore(&s->port, flags); + return ret; +} + static void max3100_work(struct work_struct *w) { struct max3100_port *s = container_of(w, struct max3100_port, work); -- 2.25.1

2 1

[PATCH OLK-6.6 0/1] psi: using cpuacct_cgrp_id under CONFIG_CGROUP_CPUACCT
by Chen Ridong 24 Jun '24

24 Jun '24

*** BLURB HERE *** Joseph Qi (1): psi: using cpuacct_cgrp_id under CONFIG_CGROUP_CPUACCT kernel/sched/psi.c | 4 ++++ 1 file changed, 4 insertions(+) -- 2.34.1

2 2

[PATCH OLK-6.6] tpm_tis_spi: Account for SPI header when allocating TPM SPI xfer buffer
by Yipeng Zou 24 Jun '24

24 Jun '24

From: "Matthew R. Ochs" <mochs(a)nvidia.com> mainline inclusion from mainline-v6.10-rc2 commit 195aba96b854dd664768f382cd1db375d8181f88 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7DAP CVE: CVE-2024-36477 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- The TPM SPI transfer mechanism uses MAX_SPI_FRAMESIZE for computing the maximum transfer length and the size of the transfer buffer. As such, it does not account for the 4 bytes of header that prepends the SPI data frame. This can result in out-of-bounds accesses and was confirmed with KASAN. Introduce SPI_HDRSIZE to account for the header and use to allocate the transfer buffer. Fixes: a86a42ac2bd6 ("tpm_tis_spi: Add hardware wait polling") Signed-off-by: Matthew R. Ochs <mochs(a)nvidia.com> Tested-by: Carol Soto <csoto(a)nvidia.com> Reviewed-by: Jarkko Sakkinen <jarkko(a)kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko(a)kernel.org> Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> --- drivers/char/tpm/tpm_tis_spi_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/char/tpm/tpm_tis_spi_main.c b/drivers/char/tpm/tpm_tis_spi_main.c index c5c3197ee29f..4bdad9e3667f 100644 --- a/drivers/char/tpm/tpm_tis_spi_main.c +++ b/drivers/char/tpm/tpm_tis_spi_main.c @@ -37,6 +37,7 @@ #include "tpm_tis_spi.h" #define MAX_SPI_FRAMESIZE 64 +#define SPI_HDRSIZE 4 /* * TCG SPI flow control is documented in section 6.4 of the spec[1]. In short, @@ -247,7 +248,7 @@ static int tpm_tis_spi_write_bytes(struct tpm_tis_data *data, u32 addr, int tpm_tis_spi_init(struct spi_device *spi, struct tpm_tis_spi_phy *phy, int irq, const struct tpm_tis_phy_ops *phy_ops) { - phy->iobuf = devm_kmalloc(&spi->dev, MAX_SPI_FRAMESIZE, GFP_KERNEL); + phy->iobuf = devm_kmalloc(&spi->dev, SPI_HDRSIZE + MAX_SPI_FRAMESIZE, GFP_KERNEL); if (!phy->iobuf) return -ENOMEM; -- 2.34.1

2 1

[PATCH OLK-6.6] f2fs: multidev: fix to recognize valid zero block address
by Yifan Qiao 24 Jun '24

24 Jun '24

From: Chao Yu <chao(a)kernel.org> mainline inclusion from mainline-v6.6-rc1 commit 33e62cd7b4c281cd737c62e5d8c4f0e602a8c5c5 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D1P CVE: CVE-2024-38636 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- As reported by Yi Zhang in mailing list [1], kernel warning was catched during zbd/010 test as below: ./check zbd/010 zbd/010 (test gap zone support with F2FS) [failed] runtime ... 3.752s something found in dmesg: [ 4378.146781] run blktests zbd/010 at 2024-02-18 11:31:13 [ 4378.192349] null_blk: module loaded [ 4378.209860] null_blk: disk nullb0 created [ 4378.413285] scsi_debug:sdebug_driver_probe: scsi_debug: trim poll_queues to 0. poll_q/nr_hw = (0/1) [ 4378.422334] scsi host15: scsi_debug: version 0191 [20210520] dev_size_mb=1024, opts=0x0, submit_queues=1, statistics=0 [ 4378.434922] scsi 15:0:0:0: Direct-Access-ZBC Linux scsi_debug 0191 PQ: 0 ANSI: 7 [ 4378.443343] scsi 15:0:0:0: Power-on or device reset occurred [ 4378.449371] sd 15:0:0:0: Attached scsi generic sg5 type 20 [ 4378.449418] sd 15:0:0:0: [sdf] Host-managed zoned block device ... (See '/mnt/tests/gitlab.com/api/v4/projects/19168116/repository/archive.zip/storage/blktests/blk/blktests/results/nodev/zbd/010.dmesg' WARNING: CPU: 22 PID: 44011 at fs/iomap/iter.c:51 CPU: 22 PID: 44011 Comm: fio Not tainted 6.8.0-rc3+ #1 RIP: 0010:iomap_iter+0x32b/0x350 Call Trace: <TASK> __iomap_dio_rw+0x1df/0x830 f2fs_file_read_iter+0x156/0x3d0 [f2fs] aio_read+0x138/0x210 io_submit_one+0x188/0x8c0 __x64_sys_io_submit+0x8c/0x1a0 do_syscall_64+0x86/0x170 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Shinichiro Kawasaki helps to analyse this issue and proposes a potential fixing patch in [2]. Quoted from reply of Shinichiro Kawasaki: "I confirmed that the trigger commit is dbf8e63f48af as Yi reported. I took a look in the commit, but it looks fine to me. So I thought the cause is not in the commit diff. I found the WARN is printed when the f2fs is set up with multiple devices, and read requests are mapped to the very first block of the second device in the direct read path. In this case, f2fs_map_blocks() and f2fs_map_blocks_cached() modify map->m_pblk as the physical block address from each block device. It becomes zero when it is mapped to the first block of the device. However, f2fs_iomap_begin() assumes that map->m_pblk is the physical block address of the whole f2fs, across the all block devices. It compares map->m_pblk against NULL_ADDR == 0, then go into the unexpected branch and sets the invalid iomap->length. The WARN catches the invalid iomap->length. This WARN is printed even for non-zoned block devices, by following steps. - Create two (non-zoned) null_blk devices memory backed with 128MB size each: nullb0 and nullb1. # mkfs.f2fs /dev/nullb0 -c /dev/nullb1 # mount -t f2fs /dev/nullb0 "${mount_dir}" # dd if=/dev/zero of="${mount_dir}/test.dat" bs=1M count=192 # dd if="${mount_dir}/test.dat" of=/dev/null bs=1M count=192 iflag=direct ..." So, the root cause of this issue is: when multi-devices feature is on, f2fs_map_blocks() may return zero blkaddr in non-primary device, which is a verified valid block address, however, f2fs_iomap_begin() treats it as an invalid block address, and then it triggers the warning in iomap framework code. Finally, as discussed, we decide to use a more simple and direct way that checking (map.m_flags & F2FS_MAP_MAPPED) condition instead of (map.m_pblk != NULL_ADDR) to fix this issue. Thanks a lot for the effort of Yi Zhang and Shinichiro Kawasaki on this issue. [1] https://lore.kernel.org/linux-f2fs-devel/CAHj4cs-kfojYC9i0G73PRkYzcxCTex=-v… [2] https://lore.kernel.org/linux-f2fs-devel/gngdj77k4picagsfdtiaa7gpgnup6fsgwz… Reported-by: Yi Zhang <yi.zhang(a)redhat.com> Closes: https://lore.kernel.org/linux-f2fs-devel/CAHj4cs-kfojYC9i0G73PRkYzcxCTex=-v… Tested-by: Shin'ichiro Kawasaki <shinichiro.kawasaki(a)wdc.com> Tested-by: Yi Zhang <yi.zhang(a)redhat.com> Fixes: 1517c1a7a445 ("f2fs: implement iomap operations") Fixes: 8d3c1fa3fa5e ("f2fs: don't rely on F2FS_MAP_* in f2fs_iomap_begin") Signed-off-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/f2fs/data.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index 5805b77d925e..5d6ba12e8448 100644 --- a/fs/f2fs/data.c +++ b/fs/f2fs/data.c @@ -4243,7 +4243,7 @@ static int f2fs_iomap_begin(struct inode *inode, loff_t offset, loff_t length, if (WARN_ON_ONCE(map.m_pblk == COMPRESS_ADDR)) return -EINVAL; - if (map.m_pblk != NULL_ADDR) { + if (map.m_flags & F2FS_MAP_MAPPED) { iomap->length = blks_to_bytes(inode, map.m_len); iomap->type = IOMAP_MAPPED; iomap->flags |= IOMAP_F_MERGED; -- 2.39.2

2 1

[PATCH OLK-6.6 0/1] psi: using cpuacct_cgrp_id under CONFIG_CGROUP_CPUACCT
by Chen Ridong 24 Jun '24

24 Jun '24

*** BLURB HERE *** Joseph Qi (1): psi: using cpuacct_cgrp_id under CONFIG_CGROUP_CPUACCT kernel/sched/psi.c | 4 ++++ 1 file changed, 4 insertions(+) -- 2.34.1

2 2

[PATCH openEuler-22.03-LTS-SP1] kprobes: Fix possible use-after-free issue on kprobe registration
by Chen Zhongjin 24 Jun '24

24 Jun '24

From: Zheng Yejian <zhengyejian1(a)huawei.com> stable inclusion from stable-v5.10.216 commit 5062d1f4f07facbdade0f402d9a04a788f52e26d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9QRI5 CVE: CVE-2024-35955 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 325f3fb551f8cd672dbbfc4cf58b14f9ee3fc9e8 upstream. When unloading a module, its state is changing MODULE_STATE_LIVE -> MODULE_STATE_GOING -> MODULE_STATE_UNFORMED. Each change will take a time. `is_module_text_address()` and `__module_text_address()` works with MODULE_STATE_LIVE and MODULE_STATE_GOING. If we use `is_module_text_address()` and `__module_text_address()` separately, there is a chance that the first one is succeeded but the next one is failed because module->state becomes MODULE_STATE_UNFORMED between those operations. In `check_kprobe_address_safe()`, if the second `__module_text_address()` is failed, that is ignored because it expected a kernel_text address. But it may have failed simply because module->state has been changed to MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modify non-exist module text address (use-after-free). To fix this problem, we should not use separated `is_module_text_address()` and `__module_text_address()`, but use only `__module_text_address()` once and do `try_module_get(module)` which is only available with MODULE_STATE_LIVE. Link: https://lore.kernel.org/all/20240410015802.265220-1-zhengyejian1@huawei.com/ Fixes: 28f6c37a2910 ("kprobes: Forbid probing on trampoline and BPF code areas") Cc: stable(a)vger.kernel.org Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> Signed-off-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> [Fix conflict due to lack dependency commit 223a76b268c9 ("kprobes: Fix coding style issues")] Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: kernel/kprobes.c [This conflict because dependency commit 1efda38d6f9b ("kprobes: Prohibit probes in gate area") not merged] Signed-off-by: Chen Zhongjin <chenzhongjin(a)huawei.com> --- kernel/kprobes.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/kernel/kprobes.c b/kernel/kprobes.c index 0990b9a5e47c..1a94cbc4572e 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -1639,9 +1639,17 @@ static int check_kprobe_address_safe(struct kprobe *p, jump_label_lock(); preempt_disable(); - /* Ensure it is not in reserved area nor out of text */ - if (!(core_kernel_text((unsigned long) p->addr) || - is_module_text_address((unsigned long) p->addr)) || + /* Ensure the address is in a text area, and find a module if exists. */ + *probed_mod = NULL; + if (!core_kernel_text((unsigned long) p->addr)) { + *probed_mod = __module_text_address((unsigned long) p->addr); + if (!(*probed_mod)) { + ret = -EINVAL; + goto out; + } + } + /* Ensure it is not in reserved area. */ + if (in_gate_area_no_mm((unsigned long) p->addr) || within_kprobe_blacklist((unsigned long) p->addr) || jump_label_text_reserved(p->addr, p->addr) || static_call_text_reserved(p->addr, p->addr) || @@ -1650,8 +1658,7 @@ static int check_kprobe_address_safe(struct kprobe *p, goto out; } - /* Check if are we probing a module */ - *probed_mod = __module_text_address((unsigned long) p->addr); + /* Get module refcount and reject __init functions for loaded modules. */ if (*probed_mod) { /* * We must hold a refcount of the probed module while updating -- 2.25.1

2 1

2024

2023

2022

2021

2020

2019

Kernel June 2024