Skip to content

DLPX-83701 Make the kernel function mnt_add_count() traceable #24

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 1 commit into from
Dec 7, 2022
Merged

DLPX-83701 Make the kernel function mnt_add_count() traceable #24

merged 1 commit into from
Dec 7, 2022

Conversation

don-brady
Copy link
Contributor

Background

Some of the kernel functions in the unmount path are not traceable which makes it harder to debug busy unmounts.

Problem

To help with diagnosing busy unmounts we should allow tracing of mnt_add_count() and do_umount() in bpftrace probes.

Solution

Augment these functions with noinline and __noclone (disables the "-fipa-sra" compilation optimization to keep the compiler from optimizing the function signatures).

Testing Done

Confirm these function symbols are traceable:

delphix@ip-10-110-220-172:~$ sudo bpftrace -l '*mnt_add_count'
kprobe:mnt_add_count
delphix@ip-10-110-220-172:~$ sudo bpftrace -l '*do_umount'
kprobe:do_umount

Also used them with a bpftrace script that watches mnt_add_count calls that decrement the mount reference after a busy unmount occurred.

@don-brady don-brady merged commit 6a84473 into delphix:6.0/stage Dec 7, 2022
delphix-devops-bot pushed a commit that referenced this pull request Dec 15, 2022
DLPX-83701 Make function mnt_add_count() traceable (#24)
a5ba399
delphix-devops-bot pushed a commit that referenced this pull request Jan 7, 2023
DLPX-83701 Make function mnt_add_count() traceable (#24)
ba72f8c
delphix-devops-bot pushed a commit that referenced this pull request Jan 16, 2023
DLPX-83701 Make function mnt_add_count() traceable (#24)
206f04f
delphix-devops-bot pushed a commit that referenced this pull request Feb 10, 2023
DLPX-83701 Make function mnt_add_count() traceable (#24)
3f117fc
delphix-devops-bot pushed a commit that referenced this pull request Mar 4, 2023
DLPX-83701 Make function mnt_add_count() traceable (#24)
d46fb7a
prakashsurya pushed a commit that referenced this pull request Mar 11, 2023
DLPX-83701 Make function mnt_add_count() traceable (#24)
41d721c
prakashsurya pushed a commit that referenced this pull request Mar 14, 2023
DLPX-83701 Make function mnt_add_count() traceable (#24)
2ede072
prakashsurya pushed a commit that referenced this pull request Mar 14, 2023
DLPX-83701 Make function mnt_add_count() traceable (#24)
1648137
delphix-devops-bot pushed a commit that referenced this pull request Mar 30, 2023
DLPX-83701 Make function mnt_add_count() traceable (#24)
aa59cdd
delphix-devops-bot pushed a commit that referenced this pull request Apr 20, 2023
DLPX-83701 Make function mnt_add_count() traceable (#24)
caf4de8
delphix-devops-bot pushed a commit that referenced this pull request Apr 28, 2023
DLPX-83701 Make function mnt_add_count() traceable (#24)
0a2b1eb
delphix-devops-bot pushed a commit that referenced this pull request May 31, 2023
DLPX-83701 Make function mnt_add_count() traceable (#24)
16e6ae5
delphix-devops-bot pushed a commit that referenced this pull request Jun 3, 2023
DLPX-83701 Make function mnt_add_count() traceable (#24)
9b71bc5
delphix-devops-bot pushed a commit that referenced this pull request Jun 4, 2023
DLPX-83701 Make function mnt_add_count() traceable (#24)
8694b31
delphix-devops-bot pushed a commit that referenced this pull request Jun 5, 2023
DLPX-83701 Make function mnt_add_count() traceable (#24)
1ce6f96
prakashsurya pushed a commit that referenced this pull request Aug 8, 2023
DLPX-83701 Make function mnt_add_count() traceable (#24)
5a84891
delphix-devops-bot pushed a commit that referenced this pull request Aug 17, 2023
DLPX-83701 Make function mnt_add_count() traceable (#24)
0394c46
delphix-devops-bot pushed a commit that referenced this pull request Aug 18, 2023
DLPX-83701 Make function mnt_add_count() traceable (#24)
bf154a2
delphix-devops-bot pushed a commit that referenced this pull request Aug 19, 2023
DLPX-83701 Make function mnt_add_count() traceable (#24)
6ec2f14
delphix-devops-bot pushed a commit that referenced this pull request Aug 20, 2023
DLPX-83701 Make function mnt_add_count() traceable (#24)
6dd8a3f
delphix-devops-bot pushed a commit that referenced this pull request Aug 21, 2023
DLPX-83701 Make function mnt_add_count() traceable (#24)
f0aad6b
delphix-devops-bot pushed a commit that referenced this pull request Aug 22, 2023
DLPX-83701 Make function mnt_add_count() traceable (#24)
6bb0e12
delphix-devops-bot pushed a commit that referenced this pull request Aug 23, 2023
DLPX-83701 Make function mnt_add_count() traceable (#24)
c3b2d11
delphix-devops-bot pushed a commit that referenced this pull request Aug 24, 2023
DLPX-83701 Make function mnt_add_count() traceable (#24)
1270d14
prakashsurya pushed a commit that referenced this pull request Sep 23, 2024
@prakashsurya
DLPX-83701 Make function mnt_add_count() traceable (#24)
3a0048a
delphix-devops-bot pushed a commit that referenced this pull request Oct 20, 2024
DLPX-83701 Make function mnt_add_count() traceable (#24)
d498114
delphix-devops-bot pushed a commit that referenced this pull request Oct 21, 2024
DLPX-83701 Make function mnt_add_count() traceable (#24)
cb94f4a
palash-gandhi pushed a commit that referenced this pull request Oct 24, 2024
@palash-gandhi
DLPX-83701 Make function mnt_add_count() traceable (#24)
892046e
delphix-devops-bot pushed a commit that referenced this pull request Nov 10, 2024
@lsahn-gh @smb49
apparmor: fix possible NULL pointer dereference
d25e388 
BugLink: https://bugs.launchpad.net/bugs/2081279

[ Upstream commit 3dd384108d53834002be5630132ad5c3f32166ad ]

profile->parent->dents[AAFS_PROF_DIR] could be NULL only if its parent is made
from __create_missing_ancestors(..) and 'ent->old' is NULL in
aa_replace_profiles(..).
In that case, it must return an error code and the code, -ENOENT represents
its state that the path of its parent is not existed yet.

BUG: kernel NULL pointer dereference, address: 0000000000000030
PGD 0 P4D 0
PREEMPT SMP PTI
CPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
RIP: 0010:aafs_create.constprop.0+0x7f/0x130
Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae
RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0
Call Trace:
 <TASK>
 ? show_regs+0x6d/0x80
 ? __die+0x24/0x80
 ? page_fault_oops+0x99/0x1b0
 ? kernelmode_fixup_or_oops+0xb2/0x140
 ? __bad_area_nosemaphore+0x1a5/0x2c0
 ? find_vma+0x34/0x60
 ? bad_area_nosemaphore+0x16/0x30
 ? do_user_addr_fault+0x2a2/0x6b0
 ? exc_page_fault+0x83/0x1b0
 ? asm_exc_page_fault+0x27/0x30
 ? aafs_create.constprop.0+0x7f/0x130
 ? aafs_create.constprop.0+0x51/0x130
 __aafs_profile_mkdir+0x3d6/0x480
 aa_replace_profiles+0x83f/0x1270
 policy_update+0xe3/0x180
 profile_load+0xbc/0x150
 ? rw_verify_area+0x47/0x140
 vfs_write+0x100/0x480
 ? __x64_sys_openat+0x55/0xa0
 ? syscall_exit_to_user_mode+0x86/0x260
 ksys_write+0x73/0x100
 __x64_sys_write+0x19/0x30
 x64_sys_call+0x7e/0x25c0
 do_syscall_64+0x7f/0x180
 entry_SYSCALL_64_after_hwframe+0x78/0x80
RIP: 0033:0x7be9f211c574
Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89
RSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574
RDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004
RBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000
R10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80
R13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30
 </TASK>
Modules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesas
CR2: 0000000000000030
---[ end trace 0000000000000000 ]---
RIP: 0010:aafs_create.constprop.0+0x7f/0x130
Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae
RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0

Signed-off-by: Leesoo Ahn <lsahn@ooseel.net>
Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Koichiro Den <koichiro.den@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
delphix-devops-bot pushed a commit that referenced this pull request Nov 10, 2024
DLPX-83701 Make function mnt_add_count() traceable (#24)
371a7a3
delphix-devops-bot pushed a commit that referenced this pull request Dec 18, 2024
DLPX-83701 Make function mnt_add_count() traceable (#24)
55e9858
delphix-devops-bot pushed a commit that referenced this pull request Dec 19, 2024
DLPX-83701 Make function mnt_add_count() traceable (#24)
a3e7af8
delphix-devops-bot pushed a commit that referenced this pull request Dec 20, 2024
DLPX-83701 Make function mnt_add_count() traceable (#24)
e850d4a
delphix-devops-bot pushed a commit that referenced this pull request Dec 21, 2024
DLPX-83701 Make function mnt_add_count() traceable (#24)
dba0657
delphix-devops-bot pushed a commit that referenced this pull request Dec 22, 2024
DLPX-83701 Make function mnt_add_count() traceable (#24)
187e331
delphix-devops-bot pushed a commit that referenced this pull request Dec 23, 2024
DLPX-83701 Make function mnt_add_count() traceable (#24)
3da20f0
delphix-devops-bot pushed a commit that referenced this pull request Dec 24, 2024
DLPX-83701 Make function mnt_add_count() traceable (#24)
43ffc00
delphix-devops-bot pushed a commit that referenced this pull request Dec 25, 2024
DLPX-83701 Make function mnt_add_count() traceable (#24)
e0d8cc5
delphix-devops-bot pushed a commit that referenced this pull request Dec 26, 2024
DLPX-83701 Make function mnt_add_count() traceable (#24)
4a875f0
delphix-devops-bot pushed a commit that referenced this pull request Dec 27, 2024
DLPX-83701 Make function mnt_add_count() traceable (#24)
a43c6ff
delphix-devops-bot pushed a commit that referenced this pull request Dec 28, 2024
DLPX-83701 Make function mnt_add_count() traceable (#24)
b6ab3fa
delphix-devops-bot pushed a commit that referenced this pull request Dec 29, 2024
DLPX-83701 Make function mnt_add_count() traceable (#24)
cc147f8
delphix-devops-bot pushed a commit that referenced this pull request Dec 30, 2024
DLPX-83701 Make function mnt_add_count() traceable (#24)
e82d91e
delphix-devops-bot pushed a commit that referenced this pull request Dec 31, 2024
DLPX-83701 Make function mnt_add_count() traceable (#24)
6783b72
delphix-devops-bot pushed a commit that referenced this pull request Jan 1, 2025
DLPX-83701 Make function mnt_add_count() traceable (#24)
f685a0e
delphix-devops-bot pushed a commit that referenced this pull request Jan 2, 2025
DLPX-83701 Make function mnt_add_count() traceable (#24)
f6a9e53
delphix-devops-bot pushed a commit that referenced this pull request Jan 3, 2025
DLPX-83701 Make function mnt_add_count() traceable (#24)
a471545
delphix-devops-bot pushed a commit that referenced this pull request Jan 4, 2025
DLPX-83701 Make function mnt_add_count() traceable (#24)
ebeaba0
delphix-devops-bot pushed a commit that referenced this pull request Jan 5, 2025
DLPX-83701 Make function mnt_add_count() traceable (#24)
fa57c83
delphix-devops-bot pushed a commit that referenced this pull request Jan 7, 2025
DLPX-83701 Make function mnt_add_count() traceable (#24)
cf4ae9d
delphix-devops-bot pushed a commit that referenced this pull request Feb 12, 2025
DLPX-83701 Make function mnt_add_count() traceable (#24)
cbb69df
delphix-devops-bot pushed a commit that referenced this pull request Feb 13, 2025
DLPX-83701 Make function mnt_add_count() traceable (#24)
13eac9f
delphix-devops-bot pushed a commit that referenced this pull request Mar 29, 2025
@mehmetb0
media: ts2020: fix null-ptr-deref in ts2020_probe()
34e2c05 
BugLink: https://bugs.launchpad.net/bugs/2095283

commit 4a058b34b52ed3feb1f3ff6fd26aefeeeed20cba upstream.

KASAN reported a null-ptr-deref issue when executing the following
command:

  # echo ts2020 0x20 > /sys/bus/i2c/devices/i2c-0/new_device
    KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
    CPU: 53 UID: 0 PID: 970 Comm: systemd-udevd Not tainted 6.12.0-rc2+ #24
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)
    RIP: 0010:ts2020_probe+0xad/0xe10 [ts2020]
    RSP: 0018:ffffc9000abbf598 EFLAGS: 00010202
    RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffffc0714809
    RDX: 0000000000000002 RSI: ffff88811550be00 RDI: 0000000000000010
    RBP: ffff888109868800 R08: 0000000000000001 R09: fffff52001577eb6
    R10: 0000000000000000 R11: ffffc9000abbff50 R12: ffffffffc0714790
    R13: 1ffff92001577eb8 R14: ffffffffc07190d0 R15: 0000000000000001
    FS:  00007f95f13b98c0(0000) GS:ffff888149280000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000555d2634b000 CR3: 0000000152236000 CR4: 00000000000006f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     ts2020_probe+0xad/0xe10 [ts2020]
     i2c_device_probe+0x421/0xb40
     really_probe+0x266/0x850
    ...

The cause of the problem is that when using sysfs to dynamically register
an i2c device, there is no platform data, but the probe process of ts2020
needs to use platform data, resulting in a null pointer being accessed.

Solve this problem by adding checks to platform data.

Fixes: dc245a5 ("[media] ts2020: implement I2C client bindings")
Cc: <stable@vger.kernel.org>
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2024-56574
Signed-off-by: Koichiro Den <koichiro.den@canonical.com>
delphix-devops-bot pushed a commit that referenced this pull request Mar 29, 2025
@jinghao-jia @mehmetb0
ipvs: fix UB due to uninitialized stack access in ip_vs_protocol_init()
959de86 
BugLink: https://bugs.launchpad.net/bugs/2095283

[ Upstream commit 146b6f1112eb30a19776d6c323c994e9d67790db ]

Under certain kernel configurations when building with Clang/LLVM, the
compiler does not generate a return or jump as the terminator
instruction for ip_vs_protocol_init(), triggering the following objtool
warning during build time:

  vmlinux.o: warning: objtool: ip_vs_protocol_init() falls through to next function __initstub__kmod_ip_vs_rr__935_123_ip_vs_rr_init6()

At runtime, this either causes an oops when trying to load the ipvs
module or a boot-time panic if ipvs is built-in. This same issue has
been reported by the Intel kernel test robot previously.

Digging deeper into both LLVM and the kernel code reveals this to be a
undefined behavior problem. ip_vs_protocol_init() uses a on-stack buffer
of 64 chars to store the registered protocol names and leaves it
uninitialized after definition. The function calls strnlen() when
concatenating protocol names into the buffer. With CONFIG_FORTIFY_SOURCE
strnlen() performs an extra step to check whether the last byte of the
input char buffer is a null character (commit 3009f89 ("fortify:
Allow strlen() and strnlen() to pass compile-time known lengths")).
This, together with possibly other configurations, cause the following
IR to be generated:

  define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #5 section ".init.text" align 16 !kcfi_type !29 {
    %1 = alloca [64 x i8], align 16
    ...

  14:                                               ; preds = %11
    %15 = getelementptr inbounds i8, ptr %1, i64 63
    %16 = load i8, ptr %15, align 1
    %17 = tail call i1 @llvm.is.constant.i8(i8 %16)
    %18 = icmp eq i8 %16, 0
    %19 = select i1 %17, i1 %18, i1 false
    br i1 %19, label %20, label %23

  20:                                               ; preds = %14
    %21 = call i64 @strlen(ptr noundef nonnull dereferenceable(1) %1) #23
    ...

  23:                                               ; preds = %14, %11, %20
    %24 = call i64 @strnlen(ptr noundef nonnull dereferenceable(1) %1, i64 noundef 64) #24
    ...
  }

The above code calculates the address of the last char in the buffer
(value %15) and then loads from it (value %16). Because the buffer is
never initialized, the LLVM GVN pass marks value %16 as undefined:

  %13 = getelementptr inbounds i8, ptr %1, i64 63
  br i1 undef, label %14, label %17

This gives later passes (SCCP, in particular) more DCE opportunities by
propagating the undef value further, and eventually removes everything
after the load on the uninitialized stack location:

  define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #0 section ".init.text" align 16 !kcfi_type !11 {
    %1 = alloca [64 x i8], align 16
    ...

  12:                                               ; preds = %11
    %13 = getelementptr inbounds i8, ptr %1, i64 63
    unreachable
  }

In this way, the generated native code will just fall through to the
next function, as LLVM does not generate any code for the unreachable IR
instruction and leaves the function without a terminator.

Zero the on-stack buffer to avoid this possible UB.

Fixes: 1da177e ("Linux-2.6.12-rc2")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202402100205.PWXIz1ZK-lkp@intel.com/
Co-developed-by: Ruowen Qin <ruqin@redhat.com>
Signed-off-by: Ruowen Qin <ruqin@redhat.com>
Signed-off-by: Jinghao Jia <jinghao7@illinois.edu>
Acked-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Koichiro Den <koichiro.den@canonical.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@pcd1193182 pcd1193182 pcd1193182 approved these changes

@sebroy sebroy sebroy approved these changes

Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@don-brady @pcd1193182 @sebroy