kernel test robot <rong.a.c...@intel.com> writes:

> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git 
> siginfo-next
>

This is an odd one.  This is the first time I recall the lkp test robot
emailing me and telling me that I have fixed an issue.  I don't mind I
am just a little surprised.

Recently it was discovered that on my branch passing a large negative signal
number to rt_sigqueueinfo could cause an oops.  The underlying issues
were fixed by:

b2a2ab527d6d ("signal: Guard against negative signal numbers in 
copy_siginfo_from_user")
a36700589b85 ("signal: Guard against negative signal numbers in 
copy_siginfo_from_user32")

It appears that this issue was found in linux-next before these fixes
were applied.  And then the top of my siginfo-next branch where these
fixes exist was tested.

I have not problem with that sequence of events it is just a little
surprising.

If I have not read this test report correctly please let me know.

Eric

> commit 601d5abfeaf244b86bb68c1e05c6e0d57be2f6b0
> Author:     Eric W. Biederman <ebied...@xmission.com>
> AuthorDate: Fri Oct 5 09:02:48 2018 +0200
> Commit:     Eric W. Biederman <ebied...@xmission.com>
> CommitDate: Mon Oct 8 09:35:26 2018 +0200
>
>     signal: In sigqueueinfo prefer sig not si_signo
>     
>     Andrei Vagin <ava...@gmail.com> reported:
>     
>     > Accoding to the man page, the user should not set si_signo, it has to 
> be set
>     > by kernel.
>     >
>     > $ man 2 rt_sigqueueinfo
>     >
>     >     The uinfo argument specifies the data to accompany  the  signal.   
> This
>     >        argument  is  a  pointer to a structure of type siginfo_t, 
> described in
>     >        sigaction(2) (and defined  by  including  <sigaction.h>).   The  
> caller
>     >        should set the following fields in this structure:
>     >
>     >        si_code
>     >               This  must  be  one of the SI_* codes in the Linux kernel 
> source
>     >               file include/asm-generic/siginfo.h, with  the  
> restriction  that
>     >               the  code  must  be  negative (i.e., cannot be SI_USER, 
> which is
>     >               used by the kernel to indicate a signal  sent  by  
> kill(2))  and
>     >               cannot  (since  Linux  2.6.39) be SI_TKILL (which is used 
> by the
>     >               kernel to indicate a signal sent using tgkill(2)).
>     >
>     >        si_pid This should be set to a process ID, typically the process 
> ID  of
>     >               the sender.
>     >
>     >        si_uid This  should  be set to a user ID, typically the real 
> user ID of
>     >               the sender.
>     >
>     >        si_value
>     >               This field contains the user data to accompany the 
> signal.   For
>     >               more information, see the description of the last (union 
> sigval)
>     >               argument of sigqueue(3).
>     >
>     >        Internally, the kernel sets the si_signo field to the  value  
> specified
>     >        in  sig,  so that the receiver of the signal can also obtain the 
> signal
>     >        number via that field.
>     >
>     > On Tue, Sep 25, 2018 at 07:19:02PM +0200, Eric W. Biederman wrote:
>     >>
>     >> If there is some application that calls sigqueueinfo directly that has
>     >> a problem with this added sanity check we can revisit this when we see
>     >> what kind of crazy that application is doing.
>     >
>     >
>     > I already know two "applications" ;)
>     >
>     > 
> https://github.com/torvalds/linux/blob/master/tools/testing/selftests/ptrace/peeksiginfo.c
>     > 
> https://github.com/checkpoint-restore/criu/blob/master/test/zdtm/static/sigpending.c
>     >
>     > Disclaimer: I'm the author of both of them.
>     
>     Looking at the kernel code the historical behavior has alwasy been to 
> prefer
>     the signal number passed in by the kernel.
>     
>     So sigh.  Implmenet __copy_siginfo_from_user and 
> __copy_siginfo_from_user32 to
>     take that signal number and prefer it.  The user of ptrace will still
>     use copy_siginfo_from_user and copy_siginfo_from_user32 as they do not and
>     never have had a signal number there.
>     
>     Luckily this change has never made it farther than linux-next.
>     
>     Fixes: e75dc036c445 ("signal: Fail sigqueueinfo if si_signo != sig")
>     Reported-by: Andrei Vagin <ava...@gmail.com>
>     Tested-by: Andrei Vagin <ava...@gmail.com>
>     Signed-off-by: "Eric W. Biederman" <ebied...@xmission.com>
>
> 4ce5f9c9e7  signal: Use a smaller struct siginfo in the kernel
> 601d5abfea  signal: In sigqueueinfo prefer sig not si_signo
> a36700589b  signal: Guard against negative signal numbers in 
> copy_siginfo_from_user32
> 771b65e89c  Add linux-next specific files for 20181011
> +------------------------------------------+------------+------------+------------+---------------+
> |                                          | 4ce5f9c9e7 | 601d5abfea | 
> a36700589b | next-20181011 |
> +------------------------------------------+------------+------------+------------+---------------+
> | boot_successes                           | 56         | 16         | 27     
>     | 8             |
> | boot_failures                            | 5          | 3          | 1      
>     | 6             |
> | EIP:__copy_user_ll                       | 1          |            |        
>     |               |
> | Mem-Info                                 | 1          | 1          | 1      
>     | 1             |
> | BUG:unable_to_handle_kernel              | 3          | 2          | 0      
>     | 2             |
> | Oops:#[##]                               | 4          | 2          | 0      
>     | 5             |
> | EIP:copy_siginfo_from_user               | 4          |            |        
>     |               |
> | Kernel_panic-not_syncing:Fatal_exception | 4          | 2          | 0      
>     | 5             |
> | EIP:known_siginfo_layout                 | 0          | 2          | 0      
>     | 5             |
> +------------------------------------------+------------+------------+------------+---------------+
>
> [child3:558] migrate_pages (294) returned ENOSYS, marking as inactive.
> [child3:558] mq_open (277) returned ENOSYS, marking as inactive.
> [child3:558] pkey_free (382) returned ENOSYS, marking as inactive.
> [child2:557] uselib (86) returned ENOSYS, marking as inactive.
> [child0:555] mq_timedreceive (280) returned ENOSYS, marking as inactive.
> [   13.686356] BUG: unable to handle kernel paging request at 34ca027e
> [   13.688081] *pdpt = 000000000c7ab001 *pde = 0000000000000000 
> [   13.697660] Oops: 0000 [#1]
> [   13.698554] CPU: 0 PID: 555 Comm: trinity-c0 Tainted: G                T 
> 4.19.0-rc1-00078-g601d5abf #1
> [   13.700926] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.10.2-1 04/01/2014
> [   13.707252] EIP: known_siginfo_layout+0x35/0x70
> [   13.708468] Code: 80 00 00 00 74 37 85 d2 7e 3b 83 f8 1f 7e 0e 83 fa 06 0f 
> 9e c0 5b 5d c3 90 8d 74 26 00 8d 48 ff bb d8 04 01 50 0f a3 cb 73 e5 <0f> b6 
> 84 00 c0 ab c0 c1 5b 5d 39 c2 0f 9e c0 c3 8d 76 00 b8 01 00
> [   13.713020] EAX: b984ab5f EBX: 500104d8 ECX: b984ab5e EDX: 000010e0
> [   13.714608] ESI: b984ab5f EDI: b70b2000 EBP: cc7b3f38 ESP: cc7b3f34
> [   13.716177] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010283
> [   13.717871] CR0: 80050033 CR2: 34ca027e CR3: 0c665560 CR4: 000406f0
> [   13.719461] DR0: b72b2000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> [   13.721066] DR6: ffff0ff0 DR7: 00000600
> [   13.722200] Call Trace:
> [   13.723069]  __copy_siginfo_from_user+0x2f/0x60
> [   13.724361]  sys_rt_tgsigqueueinfo+0x36/0x90
> [   13.729191]  do_int80_syscall_32+0x4f/0xe0
> [   13.730392]  entry_INT80_32+0xda/0xda
> [   13.731494] EIP: 0x809af42
> [   13.732413] Code: 89 c8 c3 90 8d 74 26 00 85 c0 c7 01 01 00 00 00 75 d8 a1 
> ec bd a7 08 eb d1 66 90 66 90 66 90 66 90 66 90 66 90 66 90 90 cd 80 <c3> 8d 
> b6 00 00 00 00 8d bc 27 00 00 00 00 8b 10 a3 14 be a7 08 85
> [   13.737100] EAX: ffffffda EBX: 7552a122 ECX: 00000000 EDX: b984ab5f
> [   13.738788] ESI: b70b2000 EDI: 000000ae EBP: fffffffe ESP: bfd60988
> [   13.740579] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000292
> [   13.742438] CR2: 0000000034ca027e
> [   13.743642] ---[ end trace e1fbccf706ef9461 ]---
> [   13.745144] EIP: known_siginfo_layout+0x35/0x70
>
>                                                           # HH:MM RESULT GOOD 
> BAD GOOD_BUT_DIRTY DIRTY_NOT_BAD
> git bisect start 771b65e89c8a51d611b8049718693a4202e4f732 
> 0238df646e6224016a45505d2c111a24669ebe21 --
> git bisect good bee1c1784c6492d93950701744f1066c567ec398  # 20:39  G     18   
>   0    8   8  Merge remote-tracking branch 'i2c/i2c/for-next'
> git bisect good b85fc5b27d65d27b5d67cdeadbf1ddbc740fb3e7  # 20:53  G     18   
>   0   10  10  Merge remote-tracking branch 'iommu/next'
> git bisect good 375ee3d4cd804cb24791a10c9a223b13a068e460  # 21:02  G     18   
>   0    7   7  Merge remote-tracking branch 'tty/tty-next'
> git bisect  bad 23662bdad2b2f3ff6e1abc891ed70bad0a455d98  # 21:13  B      1   
>   1    0   0  Merge remote-tracking branch 'userns/for-next'
> git bisect good 3b63b156e75d1d9010f77d512a7a3bb2f6add86a  # 21:26  G     18   
>   0   10  10  Merge remote-tracking branch 'slave-dma/next'
> git bisect good a22163785338b3dab233107c340558f2a132c15c  # 21:35  G     18   
>   0    6   6  Merge remote-tracking branch 'rpmsg/for-next'
> git bisect good 6d8099c167641e51d4b561b13c0ae350ffcda0ef  # 21:45  G     18   
>   0   11  11  Merge remote-tracking branch 'gpio/for-next'
> git bisect good 973d55984be3c3c65384b7df464d6215aae52ea9  # 21:58  G     17   
>   0    5   5  Merge remote-tracking branch 'pinctrl/for-next'
> git bisect good cd60ab7abb3df301c4ff2cf7d619cf7e30cca289  # 22:08  G     18   
>   0    8   8  signal/powerpc: Remove pkey parameter from 
> __bad_area_nosemaphore
> git bisect good c852680959d0964198e829da80f012b3df43060c  # 22:17  G     18   
>   0    7   7  signal/arm64: Use send_sig_fault where appropriate
> git bisect good 5ee527d7cefddebd72970d290e5cc06c9ae32890  # 22:27  G     18   
>   0    8   8  signal/unicore32: Use send_sig_fault where appropriate
> git bisect good f28380185193610c716a90ec9b9e696638a495ce  # 22:41  G     18   
>   0   11  11  signal: Remove the need for __ARCH_SI_PREABLE_SIZE and 
> SI_PAD_SIZE
> git bisect good ae7795bc6187a15ec51cf258abae656a625f9980  # 22:55  G     18   
>   0    6   6  signal: Distinguish between kernel_siginfo and siginfo
> git bisect  bad 601d5abfeaf244b86bb68c1e05c6e0d57be2f6b0  # 23:05  B      2   
>   1    2   2  signal: In sigqueueinfo prefer sig not si_signo
> git bisect good 4ce5f9c9e7546915c559ffae594e6d73f918db00  # 00:07  G     27   
>   0   11  11  signal: Use a smaller struct siginfo in the kernel
> # first bad commit: [601d5abfeaf244b86bb68c1e05c6e0d57be2f6b0] signal: In 
> sigqueueinfo prefer sig not si_signo
> git bisect good 4ce5f9c9e7546915c559ffae594e6d73f918db00  # 00:16  G     83   
>   0   30  41  signal: Use a smaller struct siginfo in the kernel
> # extra tests with debug options
> git bisect  bad 601d5abfeaf244b86bb68c1e05c6e0d57be2f6b0  # 00:36  B      6   
>   2    5   5  signal: In sigqueueinfo prefer sig not si_signo
> # extra tests on HEAD of linux-next/master
> git bisect  bad 771b65e89c8a51d611b8049718693a4202e4f732  # 00:36  B      3   
>   5    0   4  Add linux-next specific files for 20181011
> # extra tests on tree/branch userns/siginfo-next
> git bisect good a36700589b85443e28170be59fa11c8a104130a5  # 00:50  G     29   
>   0   10  10  signal: Guard against negative signal numbers in 
> copy_siginfo_from_user32
> # extra tests with first bad commit reverted
> git bisect good c9c9ead64294d0df96006708ba47007624c7b069  # 01:10  G     29   
>   0    9   9  Revert "signal: In sigqueueinfo prefer sig not si_signo"
> # extra tests on tree/branch linux-next/master
> git bisect  bad 771b65e89c8a51d611b8049718693a4202e4f732  # 01:10  B      3   
>   5    0   4  Add linux-next specific files for 20181011
>
> ---
> 0-DAY kernel test infrastructure                Open Source Technology Center
> https://lists.01.org/pipermail/lkp                          Intel Corporation

Reply via email to