* Re: [Ocfs2-devel] ocfs2 xattr
[not found] <ZASjOpsoM+nEx/o8@valentin-vidic.from.hr>
@ 2023-03-06 9:13 ` Roberto Sassu via Ocfs2-devel
2023-03-06 10:45 ` Valentin Vidić via Ocfs2-devel
0 siblings, 1 reply; 6+ messages in thread
From: Roberto Sassu via Ocfs2-devel @ 2023-03-06 9:13 UTC (permalink / raw
To: Valentin Vidić, ocfs2-devel
On Sun, 2023-03-05 at 15:12 +0100, Valentin Vidić wrote:
> Hi,
>
> I'm seeing the crash below on 6.1 and 6.2 kernels when trying to copy a
> directory to OCFS2 filesystem. The problem seems to be that si->name
> is NULL so strlen crashes on that. Is this a known problem related to
> the deprecated security_old_inode_init_security?
Hi Valentin
which LSMs are you running?
Thanks
Roberto
> [ 27.386786] BUG: kernel NULL pointer dereference, address: 0000000000000000
> [ 27.386818] #PF: supervisor read access in kernel mode
> [ 27.386832] #PF: error_code(0x0000) - not-present page
> [ 27.386844] PGD 0 P4D 0
> [ 27.386855] Oops: 0000 [#1] PREEMPT SMP PTI
> [ 27.386867] CPU: 0 PID: 1792 Comm: cp Not tainted 6.1.0-5-amd64 #1 Debian 6.1.12-1
> [ 27.386887] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
> [ 27.386904] RIP: 0010:strlen+0x0/0x20
> [ 27.386928] Code: b6 07 38 d0 74 14 48 83 c7 01 84 c0 74 05 48 39 f7 75 ec 31 c0 c3 cc cc cc cc 48 89 f8 c3 cc cc cc cc 0f 1f 84 00 00 00 00 00 <80> 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 cc
> [ 27.386966] RSP: 0018:ffffa33340e4fbc0 EFLAGS: 00010202
> [ 27.386980] RAX: ffff8b578c3b1800 RBX: 0000000000000001 RCX: 0000000000000000
> [ 27.386996] RDX: 0000000000000100 RSI: ffff8b57843d86e8 RDI: 0000000000000000
> [ 27.387012] RBP: ffff8b57849ca608 R08: ffffa33340e4fc7c R09: ffffa33340e4fc84
> [ 27.387027] R10: ffff8b578f1e6000 R11: ffffa33340e4fc80 R12: ffffa33340e4fcb8
> [ 27.387043] R13: ffffa33340e4fc84 R14: 00000000000041c0 R15: ffffa33340e4fc7c
> [ 27.387059] FS: 00007f7b36d50500(0000) GS:ffff8b57bec00000(0000) knlGS:0000000000000000
> [ 27.387077] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 27.387091] CR2: 0000000000000000 CR3: 000000003cfe2003 CR4: 0000000000370ef0
> [ 27.387111] Call Trace:
> [ 27.387130] <TASK>
> [ 27.387141] ocfs2_calc_xattr_init+0x7d/0x330 [ocfs2]
> [ 27.387382] ocfs2_mknod+0x471/0x1020 [ocfs2]
> [ 27.387471] ? preempt_count_add+0x6a/0xa0
> [ 27.387487] ? _raw_spin_lock+0x13/0x40
> [ 27.387506] ocfs2_mkdir+0x44/0x130 [ocfs2]
> [ 27.387583] ? security_inode_mkdir+0x3e/0x70
> [ 27.387598] vfs_mkdir+0x9c/0x140
> [ 27.387617] do_mkdirat+0x142/0x170
> [ 27.387631] __x64_sys_mkdirat+0x47/0x80
> [ 27.387643] do_syscall_64+0x58/0xc0
> [ 27.387659] ? vfs_fstatat+0x5b/0x70
> [ 27.387671] ? __do_sys_newfstatat+0x3f/0x80
> [ 27.387684] ? fpregs_assert_state_consistent+0x22/0x50
> [ 27.387698] ? exit_to_user_mode_prepare+0x3c/0x1c0
> [ 27.387712] ? syscall_exit_to_user_mode+0x17/0x40
> [ 27.387726] ? do_syscall_64+0x67/0xc0
> [ 27.387738] ? exit_to_user_mode_prepare+0x3c/0x1c0
> [ 27.387752] entry_SYSCALL_64_after_hwframe+0x63/0xcd
> [ 27.387773] RIP: 0033:0x7f7b36ee2da7
> [ 27.388191] Code: 73 01 c3 48 8b 0d 59 a0 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 02 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 29 a0 0d 00 f7 d8 64 89 01 48
> [ 27.389040] RSP: 002b:00007ffc503f3a48 EFLAGS: 00000206 ORIG_RAX: 0000000000000102
> [ 27.389474] RAX: ffffffffffffffda RBX: 00000000000001ed RCX: 00007f7b36ee2da7
> [ 27.389908] RDX: 00000000000001c0 RSI: 00007ffc503f4e4b RDI: 00000000ffffff9c
> [ 27.390347] RBP: 00007ffc503f3e50 R08: 00007ffc503f4010 R09: 0000000000000000
> [ 27.390780] R10: 00007f7b36df7960 R11: 0000000000000206 R12: 0000000000000001
> [ 27.391230] R13: 00007f7b36d50398 R14: 0000000000004000 R15: 0000000000004000
> [ 27.391677] </TASK>
> [ 27.392115] Modules linked in: ocfs2_stack_user gfs2 ocfs2 ocfs2_nodemanager ocfs2_stackglue quota_tree dlm sctp ip6_udp_tunnel udp_tunnel libcrc32c binfmt_misc intel_rapl_msr intel_rapl_common intel_pmc_core kvm_intel kvm irqbypass ghash_clmulni_intel sha512_ssse3 sha512_generic snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi aesni_intel crypto_simd cryptd snd_hda_codec rapl snd_hda_core snd_hwdep snd_pcm qxl snd_timer drm_ttm_helper pcspkr iTCO_wdt snd ttm intel_pmc_bxt iTCO_vendor_support soundcore virtio_rng button rng_core drm_kms_helper i6300esb virtio_balloon virtio_console watchdog joydev evdev serio_raw drm loop fuse dm_mod efi_pstore configfs qemu_fw_cfg ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic hid_generic usbhid hid xhci_pci xhci_hcd ahci libahci libata virtio_net net_failover virtio_blk failover usbcore scsi_mod psmouse crct10dif_pclmul crct10dif_common crc32_pclmul crc32c_intel i2c_i801 i2c_smbus scsi_common
> [ 27.392203] lpc_ich virtio_pci virtio_pci_legacy_dev virtio_pci_modern_dev usb_common virtio virtio_ring
> [ 27.396539] CR2: 0000000000000000
> [ 27.397026] ---[ end trace 0000000000000000 ]---
> [ 27.397518] RIP: 0010:strlen+0x0/0x20
> [ 27.398009] Code: b6 07 38 d0 74 14 48 83 c7 01 84 c0 74 05 48 39 f7 75 ec 31 c0 c3 cc cc cc cc 48 89 f8 c3 cc cc cc cc 0f 1f 84 00 00 00 00 00 <80> 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 cc
> [ 27.399034] RSP: 0018:ffffa33340e4fbc0 EFLAGS: 00010202
> [ 27.399556] RAX: ffff8b578c3b1800 RBX: 0000000000000001 RCX: 0000000000000000
> [ 27.400104] RDX: 0000000000000100 RSI: ffff8b57843d86e8 RDI: 0000000000000000
> [ 27.400628] RBP: ffff8b57849ca608 R08: ffffa33340e4fc7c R09: ffffa33340e4fc84
> [ 27.401153] R10: ffff8b578f1e6000 R11: ffffa33340e4fc80 R12: ffffa33340e4fcb8
> [ 27.401676] R13: ffffa33340e4fc84 R14: 00000000000041c0 R15: ffffa33340e4fc7c
> [ 27.402201] FS: 00007f7b36d50500(0000) GS:ffff8b57bec00000(0000) knlGS:0000000000000000
> [ 27.402727] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 27.403260] CR2: 0000000000000000 CR3: 000000003cfe2003 CR4: 0000000000370ef0
>
_______________________________________________
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Ocfs2-devel] ocfs2 xattr
2023-03-06 9:13 ` [Ocfs2-devel] ocfs2 xattr Roberto Sassu via Ocfs2-devel
@ 2023-03-06 10:45 ` Valentin Vidić via Ocfs2-devel
2023-03-06 16:58 ` Roberto Sassu via Ocfs2-devel
0 siblings, 1 reply; 6+ messages in thread
From: Valentin Vidić via Ocfs2-devel @ 2023-03-06 10:45 UTC (permalink / raw
To: Roberto Sassu; +Cc: ocfs2-devel
On Mon, Mar 06, 2023 at 10:13:45AM +0100, Roberto Sassu wrote:
> which LSMs are you running?
This is on Debian, so AppArmor is on by default. It seems like
only SELinux and SMACK have hooks for inode_init_security so
for other LSMs 'const char **name' would not get set?
--
Valentin
_______________________________________________
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Ocfs2-devel] ocfs2 xattr
2023-03-06 10:45 ` Valentin Vidić via Ocfs2-devel
@ 2023-03-06 16:58 ` Roberto Sassu via Ocfs2-devel
2023-03-06 21:40 ` Valentin Vidić via Ocfs2-devel
0 siblings, 1 reply; 6+ messages in thread
From: Roberto Sassu via Ocfs2-devel @ 2023-03-06 16:58 UTC (permalink / raw
To: Valentin Vidić; +Cc: ocfs2-devel
On Mon, 2023-03-06 at 11:45 +0100, Valentin Vidić wrote:
> On Mon, Mar 06, 2023 at 10:13:45AM +0100, Roberto Sassu wrote:
> > which LSMs are you running?
>
> This is on Debian, so AppArmor is on by default. It seems like
> only SELinux and SMACK have hooks for inode_init_security so
> for other LSMs 'const char **name' would not get set?
If there is no hook registering to inode_init_security, theoretically
the LSM infrastructure should return -EOPNOTSUPP, which causes ocfs2 to
set si->enable to zero, and not execute the line that causes the kernel
to panic.
The problem would arise if somehow the LSM infrastructure returns zero,
without setting the xattr. That would explain the panic.
Not sure, I will think more.
Roberto
_______________________________________________
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Ocfs2-devel] ocfs2 xattr
2023-03-06 16:58 ` Roberto Sassu via Ocfs2-devel
@ 2023-03-06 21:40 ` Valentin Vidić via Ocfs2-devel
2023-03-06 22:46 ` Valentin Vidić via Ocfs2-devel
0 siblings, 1 reply; 6+ messages in thread
From: Valentin Vidić via Ocfs2-devel @ 2023-03-06 21:40 UTC (permalink / raw
To: Roberto Sassu; +Cc: ocfs2-devel
On Mon, Mar 06, 2023 at 05:58:30PM +0100, Roberto Sassu wrote:
> If there is no hook registering to inode_init_security, theoretically
> the LSM infrastructure should return -EOPNOTSUPP, which causes ocfs2 to
> set si->enable to zero, and not execute the line that causes the kernel
> to panic.
>
> The problem would arise if somehow the LSM infrastructure returns zero,
> without setting the xattr. That would explain the panic.
>
> Not sure, I will think more.
Seems you are right. First of all, there is more than one LSM active:
[ 0.048241] LSM: initializing lsm=lockdown,capability,landlock,yama,integrity,apparmor,tomoyo,bpf
[ 0.048250] landlock: Up and running.
[ 0.048250] Yama: becoming mindful.
[ 0.048293] AppArmor: AppArmor initialized
[ 0.048295] TOMOYO Linux initialized
[ 0.048300] LSM support for eBPF active
But from the source it seems that eBPF creates all hooks and returns the
default value of 0 for inode_init_security:
include/linux/lsm_hook_defs.h:LSM_HOOK(int, 0, inode_init_security, struct inode *inode,
kernel/bpf/bpf_lsm.c:#define LSM_HOOK(RET, DEFAULT, NAME, ...) \
kernel/bpf/bpf_lsm.c:noinline RET bpf_lsm_##NAME(__VA_ARGS__) \
kernel/bpf/bpf_lsm.c:{ \
kernel/bpf/bpf_lsm.c: return DEFAULT; \
kernel/bpf/bpf_lsm.c:}
I suppose the fix would be to change the default value to -EOPNOTSUPP?
--
Valentin
_______________________________________________
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Ocfs2-devel] ocfs2 xattr
2023-03-06 21:40 ` Valentin Vidić via Ocfs2-devel
@ 2023-03-06 22:46 ` Valentin Vidić via Ocfs2-devel
2023-03-07 7:59 ` Roberto Sassu via Ocfs2-devel
0 siblings, 1 reply; 6+ messages in thread
From: Valentin Vidić via Ocfs2-devel @ 2023-03-06 22:46 UTC (permalink / raw
To: Roberto Sassu; +Cc: ocfs2-devel
On Mon, Mar 06, 2023 at 10:40:35PM +0100, Valentin Vidić wrote:
> I suppose the fix would be to change the default value to -EOPNOTSUPP?
Confirmed, new default value fixes the crash. It is essentialy the same
problem as this one in ceph:
https://github.com/torvalds/linux/commit/7f5056b9e7b71149bf11073f00a57fa1ac2921a9
I'll try to prepare a patch...
--
Valentin
_______________________________________________
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Ocfs2-devel] ocfs2 xattr
2023-03-06 22:46 ` Valentin Vidić via Ocfs2-devel
@ 2023-03-07 7:59 ` Roberto Sassu via Ocfs2-devel
0 siblings, 0 replies; 6+ messages in thread
From: Roberto Sassu via Ocfs2-devel @ 2023-03-07 7:59 UTC (permalink / raw
To: Valentin Vidić; +Cc: ocfs2-devel
On Mon, 2023-03-06 at 23:46 +0100, Valentin Vidić wrote:
> On Mon, Mar 06, 2023 at 10:40:35PM +0100, Valentin Vidić wrote:
> > I suppose the fix would be to change the default value to -EOPNOTSUPP?
>
> Confirmed, new default value fixes the crash. It is essentialy the same
> problem as this one in ceph:
>
> https://github.com/torvalds/linux/commit/7f5056b9e7b71149bf11073f00a57fa1ac2921a9
>
> I'll try to prepare a patch...
Ok, yes. It is a known problem. I tried to fix it several times, but no
luck yet.
https://lore.kernel.org/bpf/20221115175652.3836811-1-roberto.sassu@huaweicloud.com/
https://lore.kernel.org/bpf/20221207172434.435893-1-roberto.sassu@huaweicloud.com/
If you change the default value to -EOPNOTSUPP, that would address the
problem if no eBPF program attaches to the inode_init_security hook. If
one does and returns zero or any positive value, the kernel cannot
handle it.
Roberto
_______________________________________________
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-03-07 7:59 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <ZASjOpsoM+nEx/o8@valentin-vidic.from.hr>
2023-03-06 9:13 ` [Ocfs2-devel] ocfs2 xattr Roberto Sassu via Ocfs2-devel
2023-03-06 10:45 ` Valentin Vidić via Ocfs2-devel
2023-03-06 16:58 ` Roberto Sassu via Ocfs2-devel
2023-03-06 21:40 ` Valentin Vidić via Ocfs2-devel
2023-03-06 22:46 ` Valentin Vidić via Ocfs2-devel
2023-03-07 7:59 ` Roberto Sassu via Ocfs2-devel
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.