Kernel panic because of wrong contents in core_pattern

Kernel panic because of wrong contents in core_pattern

[Dietmar Hahn]

Hi,

#uname -r
5.4.0-rc7-10.g62d06a0-default+

we use our own core dump utility and by mistake I did:
# echo "| /opt/SMAW/X2000/bin/x2write_core %p" > /proc/sys/kernel/core_pattern

Later a user tool dumped with SIGSEGV and the linux system crashed.
I investigated the crash dump and found the cause.

Via format_corename() in fs/coredump.c the helper_argv[] with 3 entries is
created and helper_argv[0] == "" (because of the ' ' after the '|')
ispipe is set to 1.
Later in call_usermodehelper_setup():
  sub_info->path = path;  == helper_argv[0] == ""
This leads in call_usermodehelper_exec() to:
  if (strlen(sub_info->path) == 0)
                goto out;
with a return value of 0.
But no pipe is created and thus cprm.file == NULL.
This leads in file_start_write() to the panic because of dereferencing
 file_inode(file)->i_mode)

I'am not sure what's the best way to fix this so I've no patch.
Thanks.

Dietmar.


[  249.719984] a[8204]: segfault at 1 ip 00007f7fe523e3c1 sp 00007ffe9ecf03c0 error 4 in libc-2.22.so[7f7fe51f4000+19c000]
[  249.719989] Code: 4c 8b 85 28 fb ff ff 44 29 e8 48 98 49 39 c1 0f 87 a2 f7 ff ff 44 03 ad 20 fb ff ff e9 02 ec ff ff 31 c0 48 83 c9 ff 4c 89 d7 <f2> ae c7 85 28 fb ff ff 00 00 00 00 48 89 ce 48 f7 d6 4c 8d 4e ff
[  489.128821] a[20151]: segfault at 1 ip 00007fd584f603c1 sp 00007ffe98182c30 error 4 in libc-2.22.so[7fd584f16000+19c000]
[  489.128827] Code: 4c 8b 85 28 fb ff ff 44 29 e8 48 98 49 39 c1 0f 87 a2 f7 ff ff 44 03 ad 20 fb ff ff e9 02 ec ff ff 31 c0 48 83 c9 ff 4c 89 d7 <f2> ae c7 85 28 fb ff ff 00 00 00 00 48 89 ce 48 f7 d6 4c 8d 4e ff
[  489.128839] BUG: kernel NULL pointer dereference, address: 0000000000000020
[  489.152546] #PF: supervisor read access in kernel mode
[  489.170234] #PF: error_code(0x0000) - not-present page
[  489.187917] PGD 8000000318008067 P4D 8000000318008067 PUD 31b40b067 PMD 0
[  489.211343] Oops: 0000 [#1] SMP PTI
[  489.223600] CPU: 0 PID: 20151 Comm: a Kdump: loaded Tainted: G          I E     5.4.0-rc7-10.g62d06a0-default+ #1
[  489.258196] Hardware name: FUJITSU                          PRIMERGY TX300 S5             /D2619, BIOS 6.00 Rev. 1.14.2619              02/04/2013
[  489.303082] RIP: 0010:do_coredump+0x717/0xb10
[  489.318229] Code: ff 48 8b bd 18 ff ff ff 48 85 ff 74 05 e8 e1 5b fa ff 65 48 8b 04 25 c0 8b 01 00 48 8b 00 48 8b 7d a0 a8 04 0f 85 fe 02 00 00 <48> 8b 57 20 0f b7 02 66 25 00 f0 66 3d 00 80 0f 84 a2 01 00 00 48
[  489.381755] RSP: 0000:ffffaedc80a67cd0 EFLAGS: 00010246
[  489.399795] RAX: 0000000000000000 RBX: ffff9b68dcee72c0 RCX: 0000000000000000
[  489.424137] RDX: 0000000000000000 RSI: ffffaedc80a67ca0 RDI: 0000000000000000
[  489.448464] RBP: ffffaedc80a67df8 R08: 0000000000000000 R09: ffffaedc80a67c28
[  489.472806] R10: 0000000000001f30 R11: 0000000000000001 R12: ffff9b68dfa08cc0
[  489.497150] R13: 0000000000000001 R14: ffffffff8ed205a0 R15: ffff9b68dcefe1e0
[  489.521493] FS:  00007fd5854c6700(0000) GS:ffff9b68ffc00000(0000) knlGS:0000000000000000
[  489.548997] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  489.568776] CR2: 0000000000000020 CR3: 00000003180fe000 CR4: 00000000000006f0
[  489.593145] Call Trace:
[  489.602067]  ? sched_clock+0x5/0x10
[  489.614420]  ? _raw_spin_lock_irqsave+0x20/0x50
[  489.630206]  get_signal+0x13c/0x860
[  489.642560]  ? printk+0x52/0x6e
[  489.653767]  do_signal+0x36/0x630
[  489.665538]  ? signal_wake_up_state+0x15/0x30
[  489.680743]  ? __send_signal+0x287/0x3f0
[  489.694514]  exit_to_usermode_loop+0x95/0x130
[  489.709705]  prepare_exit_to_usermode+0x98/0xd0
[  489.725462]  retint_user+0x8/0x18
[  489.737208] RIP: 0033:0x7fd584f603c1
[  489.749801] Code: 4c 8b 85 28 fb ff ff 44 29 e8 48 98 49 39 c1 0f 87 a2 f7 ff ff 44 03 ad 20 fb ff ff e9 02 ec ff ff 31 c0 48 83 c9 ff 4c 89 d7 <f2> ae c7 85 28 fb ff ff 00 00 00 00 48 89 ce 48 f7 d6 4c 8d 4e ff
[  489.813373] RSP: 002b:00007ffe98182c30 EFLAGS: 00010286
[  489.831437] RAX: 0000000000000000 RBX: 00007fd5852b62a0 RCX: ffffffffffffffff
[  489.855810] RDX: 0000000000000010 RSI: 00007ffe98183188 RDI: 0000000000000001
[  489.880186] RBP: 00007ffe981831c0 R08: 00000000004005fa R09: 0000000000000073
[  489.904551] R10: 0000000000000001 R11: 0000000000000000 R12: 00000000004005f4
[  489.928910] R13: 0000000000000006 R14: 0000000000000000 R15: 00007ffe981831d8
[  489.953261] Modules linked in: binfmt_misc(E) ebtable_filter(E) ebtables(E) ip6table_filter(E) ip6_tables(E) iptable_filter(E) ip_tables(E) x_tables(E) bpfilter(E) rpcsec_gss_krb5(E) auth_rpcgss(E) nfsv4(E) dns_resolver(E) nfs(E) lockd(E) grace(E) sunrpc(E) fscache(E) scsi_transport_iscsi(E) mptctl(E) mptbase(E) af_packet(E) bonding(E) iscsi_ibft(E) iscsi_boot_sysfs(E) intel_powerclamp(E) coretemp(E) kvm_intel(E) kvm(E) igb(E) msr(E) lpc_ich(E) mfd_core(E) pcspkr(E) irqbypass(E) i2c_i801(E) raid1(E) md_mod(E) ses(E) enclosure(E) scsi_transport_sas(E) ipmi_si(E) ipmi_devintf(E) ipmi_msghandler(E) ac(E) ioatdma(E) i7core_edac(E) i5500_temp(E) dca(E) ext4(E) crc16(E) mbcache(E) jbd2(E) hid_generic(E) usbhid(E) sd_mod(E) sr_mod(E) cdrom(E) mgag200(E) drm_vram_helper(E) i2c_algo_bit(E) ata_generic(E) ata_piix(E) drm_kms_helper(E) syscopyarea(E) ahci(E) sysfillrect(E) sysimgblt(E) libahci(E) fb_sys_fops(E) uhci_hcd(E) ttm(E) ehci_pci(E) crc32c_intel(E) ehci_hcd(E) libata(E) drm(E) usbcore(E)
[  489.953296]  megaraid_sas(E) button(E) sg(E) dm_multipath(E) dm_mod(E) scsi_dh_rdac(E) scsi_dh_emc(E) scsi_dh_alua(E) scsi_mod(E)
[  490.288829] CR2: 0000000000000020

Re: Kernel panic because of wrong contents in core_pattern

[Al Viro]

On Fri, Nov 15, 2019 at 02:01:55PM +0100, Dietmar Hahn wrote:

> Later a user tool dumped with SIGSEGV and the linux system crashed.
> I investigated the crash dump and found the cause.
> 
> Via format_corename() in fs/coredump.c the helper_argv[] with 3 entries is
> created and helper_argv[0] == "" (because of the ' ' after the '|')
> ispipe is set to 1.
> Later in call_usermodehelper_setup():
>   sub_info->path = path;  == helper_argv[0] == ""
> This leads in call_usermodehelper_exec() to:
>   if (strlen(sub_info->path) == 0)
>                 goto out;
> with a return value of 0.
> But no pipe is created and thus cprm.file == NULL.
> This leads in file_start_write() to the panic because of dereferencing
>  file_inode(file)->i_mode)
> 
> I'am not sure what's the best way to fix this so I've no patch.
> Thanks.

Check in the caller of format_corename() for **argv being '\0' and fail
if it is?  I mean, turn that
                if (ispipe < 0) {
                        printk(KERN_WARNING "format_corename failed\n");
                        printk(KERN_WARNING "Aborting core\n");
                        goto fail_unlock;
                }   
in there into
		if (ispipe < 0 || !**argv) {
                        printk(KERN_WARNING "format_corename failed\n");
                        printk(KERN_WARNING "Aborting core\n");
                        goto fail_unlock;
                }

Re: Kernel panic because of wrong contents in core_pattern

[Dietmar Hahn]

Am Freitag, 15. November 2019, 14:27:40 CET schrieb Al Viro:
> On Fri, Nov 15, 2019 at 02:01:55PM +0100, Dietmar Hahn wrote:
> 
> > Later a user tool dumped with SIGSEGV and the linux system crashed.
> > I investigated the crash dump and found the cause.
> > 
> > Via format_corename() in fs/coredump.c the helper_argv[] with 3 entries is
> > created and helper_argv[0] == "" (because of the ' ' after the '|')
> > ispipe is set to 1.
> > Later in call_usermodehelper_setup():
> >   sub_info->path = path;  == helper_argv[0] == ""
> > This leads in call_usermodehelper_exec() to:
> >   if (strlen(sub_info->path) == 0)
> >                 goto out;
> > with a return value of 0.
> > But no pipe is created and thus cprm.file == NULL.
> > This leads in file_start_write() to the panic because of dereferencing
> >  file_inode(file)->i_mode)
> > 
> > I'am not sure what's the best way to fix this so I've no patch.
> > Thanks.
> 
> Check in the caller of format_corename() for **argv being '\0' and fail
> if it is?  I mean, turn that
>                 if (ispipe < 0) {
>                         printk(KERN_WARNING "format_corename failed\n");
>                         printk(KERN_WARNING "Aborting core\n");
>                         goto fail_unlock;
>                 }   
> in there into
> 		if (ispipe < 0 || !**argv) {
>                         printk(KERN_WARNING "format_corename failed\n");
>                         printk(KERN_WARNING "Aborting core\n");
>                         goto fail_unlock;
>                 }

Unfortunately this doesn't work because argv[0] is always 0 in case of ispipe
in format_corename():
	if (ispipe) {
		int argvs = sizeof(core_pattern) / 2;
		(*argv) = kmalloc_array(argvs, sizeof(**argv), GFP_KERNEL);
		if (!(*argv))
			return -ENOMEM;
		(*argv)[(*argc)++] = 0;
		++pat_ptr;
	}

The manpage says: The program must be ..., and must immediately
follow the '|' character.
Why not check this in format_corename(), maybe:

@@ -211,6 +211,8 @@ static int format_corename(struct core_name *cn, struct coredump_params *cprm,
                        return -ENOMEM;
                (*argv)[(*argc)++] = 0;
                ++pat_ptr;
+               if (isspace(*pat_ptr))
+                       return -EINVAL;
        }

Dietmar.