* Re: autofs crash with latest linux-next [not found] <yt9d1ri3nakg.fsf@linux.ibm.com> @ 2020-10-13 7:20 ` Christian Borntraeger 2020-10-14 7:15 ` Krzysztof Kozlowski 0 siblings, 1 reply; 5+ messages in thread From: Christian Borntraeger @ 2020-10-13 7:20 UTC (permalink / raw) To: Sven Schnelle, Linus Torvalds, Christoph Hellwig Cc: linux-kernel, Linux-Next Mailing List, viro@zeniv.linux.org.uk CC linux-next, Al Viro. On 12.10.20 09:54, Sven Schnelle wrote: > Hi, > > on s390 i see the following crash with linux-next: > > [ 4525.432605] Unable to handle kernel pointer dereference in virtual kernel address space > [ 4525.432612] Failing address: 0000000000000000 TEID: 0000000000000483 > [ 4525.432613] Fault in home space mode while using kernel ASCE. > [ 4525.432616] AS:00000000cf048007 R3:00000001fffec007 S:00000001ffff1800 P:000000000000003d > [ 4525.432640] Oops: 0004 ilc:3 [#1] SMP > [ 4525.432644] Modules linked in: dm_crypt encrypted_keys lcs ctcm fsm nfsv3 nfs_acl nfs lockd grace quota_v2 quota_tree tun overlay ntfs exfat vfat fat sctp vfio_pci irqbypass vfio_virqfd scsi_debug vhost_vsock vmw_vsock_virtio_transport_common vsock vhost vhost_iotlb vfio_ap kvm loop nft_counter bridge stp llc dm_service_time nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables nfnetlink sunrpc dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua s390_trng vfio_ccw vfio_mdev mdev vfio_iommu_type1 vfio zcrypt_cex4 eadm_sch sch_fq_codel ip_tables x_tables ghash_s390 prng aes_s390 des_s390 libdes sha3_512_s390 sha3_256_s390 sha512_s390 sha256_s390 sha1_s390 sha_common pkey zcrypt rng_core autofs4 [last unloaded: dummy_del_mod] > [ 4525.432691] CPU: 9 PID: 1050921 Comm: find Tainted: G OE 5.9.0-20201011.rc8.git0.d67bc7812221.300.fc32.s390x+next #1 > [ 4525.432693] Hardware name: IBM 3906 M04 704 (LPAR) > [ 4525.432694] Krnl PSW : 0704d00180000000 00000000cde29f70 (__kernel_write+0x1a0/0x2a0) > [ 4525.432702] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 > [ 4525.432704] Krnl GPRS: 0000000100067343 0000000000000000 0000000000000130 0000000000000001 > [ 4525.432705] 0000000000000006 000000005f82be2f 0000000000000130 000000008c6ab568 > [ 4525.432728] 0000000084441f00 0000000000000000 0000000000000130 0000000084441f00 > [ 4525.432729] 0000000081476000 0000000000000001 00000000cde29ef4 000003e002f5b6f0 > [ 4525.432735] Krnl Code: 00000000cde29f62: a7280000 lhi %r2,0 > 00000000cde29f66: a7f4ff9d brc 15,00000000cde29ea0 > #00000000cde29f6a: e310f0f00004 lg %r1,240(%r15) > >00000000cde29f70: e31090000024 stg %r1,0(%r9) > 00000000cde29f76: 9104b044 tm 68(%r11),4 > 00000000cde29f7a: a784000f brc 8,00000000cde29f98 > 00000000cde29f7e: e31003400004 lg %r1,832 > 00000000cde29f84: b904002a lgr %r2,%r10 > [ 4525.432748] Call Trace: > [ 4525.432750] [<00000000cde29f70>] __kernel_write+0x1a0/0x2a0 > [ 4525.432752] ([<00000000cde29ef4>] __kernel_write+0x124/0x2a0) > [ 4525.432756] [<000003ff80004cfa>] autofs_write+0x5a/0x140 [autofs4] > [ 4525.432758] [<000003ff80005262>] autofs_notify_daemon.constprop.0+0x10a/0x1c8 [autofs4] > [ 4525.432760] [<000003ff80005872>] autofs_wait+0x552/0x718 [autofs4] > [ 4525.432762] [<000003ff800033ca>] autofs_mount_wait+0x5a/0xb0 [autofs4] > [ 4525.432764] [<000003ff800048b2>] autofs_d_automount+0x102/0x278 [autofs4] > [ 4525.432766] [<00000000cde398fe>] __traverse_mounts+0x9e/0x270 > [ 4525.432768] [<00000000cde3e7ee>] step_into+0x1de/0x280 > [ 4525.432770] [<00000000cde3f000>] open_last_lookups+0xb8/0x3f8 > [ 4525.432772] [<00000000cde3f726>] path_openat+0x86/0x1d0 > [ 4525.432773] [<00000000cde425b0>] do_filp_open+0x78/0x118 > [ 4525.432776] [<00000000cde278d0>] do_sys_openat2+0xa8/0x168 > [ 4525.432778] [<00000000cde27cfa>] __s390x_sys_openat+0x6a/0x98 > [ 4525.432781] [<00000000ce64f2e8>] system_call+0xdc/0x2a4 > [ 4525.432782] Last Breaking-Event-Address: > [ 4525.432783] [<00000000cde29efc>] __kernel_write+0x12c/0x2a0 > > This seems to be caused by the result of merging 0fb702791bf ("autofs: > use __kernel_write() for the autofs pipe writing") and 4d03e3cc5982 I cannot find the first commit ids. To me it looks like this should be commit 90fb702791bf99b959006972e8ee7bb4609f441b Author: Linus Torvalds <torvalds@linux-foundation.org> AuthorDate: Tue Sep 29 17:18:34 2020 -0700 Commit: Linus Torvalds <torvalds@linux-foundation.org> CommitDate: Tue Sep 29 17:18:34 2020 -0700 autofs: use __kernel_write() for the autofs pipe writing instead? > ("fs: don't allow kernel reads and writes without iter > ops"). __kernel_write() gets now called with a NULL pointer as pos > argument, but __kernel_write expects a valid pointer as it > fetches/stores the pos value there. Is there a fix pending somewhere? > > Thanks > Sven > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: autofs crash with latest linux-next 2020-10-13 7:20 ` autofs crash with latest linux-next Christian Borntraeger @ 2020-10-14 7:15 ` Krzysztof Kozlowski 2020-10-15 19:28 ` Kees Cook 0 siblings, 1 reply; 5+ messages in thread From: Krzysztof Kozlowski @ 2020-10-14 7:15 UTC (permalink / raw) To: Christian Borntraeger Cc: Sven Schnelle, Linus Torvalds, Christoph Hellwig, linux-kernel, Linux-Next Mailing List, viro@zeniv.linux.org.uk, Kees Cook On Tue, Oct 13, 2020 at 09:20:12AM +0200, Christian Borntraeger wrote: > CC linux-next, Al Viro. > > On 12.10.20 09:54, Sven Schnelle wrote: > > Hi, > > > > on s390 i see the following crash with linux-next: > > > > [ 4525.432605] Unable to handle kernel pointer dereference in virtual kernel address space > > [ 4525.432612] Failing address: 0000000000000000 TEID: 0000000000000483 > > [ 4525.432613] Fault in home space mode while using kernel ASCE. > > [ 4525.432616] AS:00000000cf048007 R3:00000001fffec007 S:00000001ffff1800 P:000000000000003d > > [ 4525.432640] Oops: 0004 ilc:3 [#1] SMP > > [ 4525.432644] Modules linked in: dm_crypt encrypted_keys lcs ctcm fsm nfsv3 nfs_acl nfs lockd grace quota_v2 quota_tree tun overlay ntfs exfat vfat fat sctp vfio_pci irqbypass vfio_virqfd scsi_debug vhost_vsock vmw_vsock_virtio_transport_common vsock vhost vhost_iotlb vfio_ap kvm loop nft_counter bridge stp llc dm_service_time nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables nfnetlink sunrpc dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua s390_trng vfio_ccw vfio_mdev mdev vfio_iommu_type1 vfio zcrypt_cex4 eadm_sch sch_fq_codel ip_tables x_tables ghash_s390 prng aes_s390 des_s390 libdes sha3_512_s390 sha3_256_s390 sha512_s390 sha256_s390 sha1_s390 sha_common pkey zcrypt rng_core autofs4 [last unloaded: dummy_del_mod] > > [ 4525.432691] CPU: 9 PID: 1050921 Comm: find Tainted: G OE 5.9.0-20201011.rc8.git0.d67bc7812221.300.fc32.s390x+next #1 > > [ 4525.432693] Hardware name: IBM 3906 M04 704 (LPAR) > > [ 4525.432694] Krnl PSW : 0704d00180000000 00000000cde29f70 (__kernel_write+0x1a0/0x2a0) > > [ 4525.432702] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 > > [ 4525.432704] Krnl GPRS: 0000000100067343 0000000000000000 0000000000000130 0000000000000001 > > [ 4525.432705] 0000000000000006 000000005f82be2f 0000000000000130 000000008c6ab568 > > [ 4525.432728] 0000000084441f00 0000000000000000 0000000000000130 0000000084441f00 > > [ 4525.432729] 0000000081476000 0000000000000001 00000000cde29ef4 000003e002f5b6f0 > > [ 4525.432735] Krnl Code: 00000000cde29f62: a7280000 lhi %r2,0 > > 00000000cde29f66: a7f4ff9d brc 15,00000000cde29ea0 > > #00000000cde29f6a: e310f0f00004 lg %r1,240(%r15) > > >00000000cde29f70: e31090000024 stg %r1,0(%r9) > > 00000000cde29f76: 9104b044 tm 68(%r11),4 > > 00000000cde29f7a: a784000f brc 8,00000000cde29f98 > > 00000000cde29f7e: e31003400004 lg %r1,832 > > 00000000cde29f84: b904002a lgr %r2,%r10 > > [ 4525.432748] Call Trace: > > [ 4525.432750] [<00000000cde29f70>] __kernel_write+0x1a0/0x2a0 > > [ 4525.432752] ([<00000000cde29ef4>] __kernel_write+0x124/0x2a0) > > [ 4525.432756] [<000003ff80004cfa>] autofs_write+0x5a/0x140 [autofs4] > > [ 4525.432758] [<000003ff80005262>] autofs_notify_daemon.constprop.0+0x10a/0x1c8 [autofs4] > > [ 4525.432760] [<000003ff80005872>] autofs_wait+0x552/0x718 [autofs4] > > [ 4525.432762] [<000003ff800033ca>] autofs_mount_wait+0x5a/0xb0 [autofs4] > > [ 4525.432764] [<000003ff800048b2>] autofs_d_automount+0x102/0x278 [autofs4] > > [ 4525.432766] [<00000000cde398fe>] __traverse_mounts+0x9e/0x270 > > [ 4525.432768] [<00000000cde3e7ee>] step_into+0x1de/0x280 > > [ 4525.432770] [<00000000cde3f000>] open_last_lookups+0xb8/0x3f8 > > [ 4525.432772] [<00000000cde3f726>] path_openat+0x86/0x1d0 > > [ 4525.432773] [<00000000cde425b0>] do_filp_open+0x78/0x118 > > [ 4525.432776] [<00000000cde278d0>] do_sys_openat2+0xa8/0x168 > > [ 4525.432778] [<00000000cde27cfa>] __s390x_sys_openat+0x6a/0x98 > > [ 4525.432781] [<00000000ce64f2e8>] system_call+0xdc/0x2a4 > > [ 4525.432782] Last Breaking-Event-Address: > > [ 4525.432783] [<00000000cde29efc>] __kernel_write+0x12c/0x2a0 > > > > This seems to be caused by the result of merging 0fb702791bf ("autofs: > > use __kernel_write() for the autofs pipe writing") and 4d03e3cc5982 > > I cannot find the first commit ids. To me it looks like this should be > > commit 90fb702791bf99b959006972e8ee7bb4609f441b > Author: Linus Torvalds <torvalds@linux-foundation.org> > AuthorDate: Tue Sep 29 17:18:34 2020 -0700 > Commit: Linus Torvalds <torvalds@linux-foundation.org> > CommitDate: Tue Sep 29 17:18:34 2020 -0700 > > autofs: use __kernel_write() for the autofs pipe writing > > instead? > > > > ("fs: don't allow kernel reads and writes without iter > > ops"). __kernel_write() gets now called with a NULL pointer as pos > > argument, but __kernel_write expects a valid pointer as it > > fetches/stores the pos value there. Is there a fix pending somewhere? Hi All, +CC Kees Cook (reviewer), I hit this since few days as well. Although the bisect points to the merge, the issue looks like a result of mentioned commit 4d03e3cc5982 ("fs: don't allow kernel reads and writes without iter ops"). The __kernel_read() last argument 'pos' can be NULL and it is dereferenced here (added by the commit): 525 ssize_t __kernel_write(struct file *file, const void *buf, size_t count, loff_t *pos) ... 547 kiocb.ki_pos = *pos; 548 iov_iter_kvec(&iter, WRITE, &iov, 1, iov.iov_len); The __kernel_read() is called with NULL in fs/autofs/waitq.c: 45 static int autofs_write(struct autofs_sb_info *sbi, 46 struct file *file, const void *addr, int bytes) ... 54 mutex_lock(&sbi->pipe_mutex); 55 while (bytes) { 56 wr = __kernel_write(file, data, bytes, NULL); Best regards, Krzysztof ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: autofs crash with latest linux-next 2020-10-14 7:15 ` Krzysztof Kozlowski @ 2020-10-15 19:28 ` Kees Cook 2020-10-15 19:58 ` Krzysztof Kozlowski 2020-10-16 5:44 ` Sven Schnelle 0 siblings, 2 replies; 5+ messages in thread From: Kees Cook @ 2020-10-15 19:28 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Christian Borntraeger, Sven Schnelle, Linus Torvalds, Christoph Hellwig, linux-kernel, Linux-Next Mailing List, viro@zeniv.linux.org.uk On Wed, Oct 14, 2020 at 09:15:47AM +0200, Krzysztof Kozlowski wrote: > I hit this since few days as well. Although the bisect points to the > merge, the issue looks like a result of mentioned commit 4d03e3cc5982 > ("fs: don't allow kernel reads and writes without iter ops"). > > The __kernel_read() last argument 'pos' can be NULL and it is > dereferenced here (added by the commit): > > 525 ssize_t __kernel_write(struct file *file, const void *buf, size_t count, loff_t *pos) > ... > 547 kiocb.ki_pos = *pos; > 548 iov_iter_kvec(&iter, WRITE, &iov, 1, iov.iov_len); > > > The __kernel_read() is called with NULL in fs/autofs/waitq.c: > > 45 static int autofs_write(struct autofs_sb_info *sbi, > 46 struct file *file, const void *addr, int bytes) > > ... > 54 mutex_lock(&sbi->pipe_mutex); > 55 while (bytes) { > 56 wr = __kernel_write(file, data, bytes, NULL); I think the thread here is the same thing, but you've found it in autofs... https://lore.kernel.org/lkml/CAHk-=wgj=mKeN-EfV5tKwJNeHPLG0dybq+R5ZyGuc4WeUnqcmA@mail.gmail.com/ -- Kees Cook ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: autofs crash with latest linux-next 2020-10-15 19:28 ` Kees Cook @ 2020-10-15 19:58 ` Krzysztof Kozlowski 2020-10-16 5:44 ` Sven Schnelle 1 sibling, 0 replies; 5+ messages in thread From: Krzysztof Kozlowski @ 2020-10-15 19:58 UTC (permalink / raw) To: Kees Cook Cc: Christian Borntraeger, Sven Schnelle, Linus Torvalds, Christoph Hellwig, linux-kernel@vger.kernel.org, Linux-Next Mailing List, viro@zeniv.linux.org.uk On Thu, 15 Oct 2020 at 21:28, Kees Cook <keescook@chromium.org> wrote: > > On Wed, Oct 14, 2020 at 09:15:47AM +0200, Krzysztof Kozlowski wrote: > > I hit this since few days as well. Although the bisect points to the > > merge, the issue looks like a result of mentioned commit 4d03e3cc5982 > > ("fs: don't allow kernel reads and writes without iter ops"). > > > > The __kernel_read() last argument 'pos' can be NULL and it is > > dereferenced here (added by the commit): > > > > 525 ssize_t __kernel_write(struct file *file, const void *buf, size_t count, loff_t *pos) > > ... > > 547 kiocb.ki_pos = *pos; > > 548 iov_iter_kvec(&iter, WRITE, &iov, 1, iov.iov_len); > > > > > > The __kernel_read() is called with NULL in fs/autofs/waitq.c: > > > > 45 static int autofs_write(struct autofs_sb_info *sbi, > > 46 struct file *file, const void *addr, int bytes) > > > > ... > > 54 mutex_lock(&sbi->pipe_mutex); > > 55 while (bytes) { > > 56 wr = __kernel_write(file, data, bytes, NULL); > > I think the thread here is the same thing, but you've found it in > autofs... > https://lore.kernel.org/lkml/CAHk-=wgj=mKeN-EfV5tKwJNeHPLG0dybq+R5ZyGuc4WeUnqcmA@mail.gmail.com/ Indeed it looks the same. Thanks for the pointer. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: autofs crash with latest linux-next 2020-10-15 19:28 ` Kees Cook 2020-10-15 19:58 ` Krzysztof Kozlowski @ 2020-10-16 5:44 ` Sven Schnelle 1 sibling, 0 replies; 5+ messages in thread From: Sven Schnelle @ 2020-10-16 5:44 UTC (permalink / raw) To: Kees Cook Cc: Krzysztof Kozlowski, Christian Borntraeger, Linus Torvalds, Christoph Hellwig, linux-kernel, Linux-Next Mailing List, viro@zeniv.linux.org.uk Kees Cook <keescook@chromium.org> writes: > On Wed, Oct 14, 2020 at 09:15:47AM +0200, Krzysztof Kozlowski wrote: >> I hit this since few days as well. Although the bisect points to the >> merge, the issue looks like a result of mentioned commit 4d03e3cc5982 >> ("fs: don't allow kernel reads and writes without iter ops"). >> >> The __kernel_read() last argument 'pos' can be NULL and it is >> dereferenced here (added by the commit): >> >> 525 ssize_t __kernel_write(struct file *file, const void *buf, size_t count, loff_t *pos) >> ... >> 547 kiocb.ki_pos = *pos; >> 548 iov_iter_kvec(&iter, WRITE, &iov, 1, iov.iov_len); >> >> >> The __kernel_read() is called with NULL in fs/autofs/waitq.c: >> >> 45 static int autofs_write(struct autofs_sb_info *sbi, >> 46 struct file *file, const void *addr, int bytes) >> >> ... >> 54 mutex_lock(&sbi->pipe_mutex); >> 55 while (bytes) { >> 56 wr = __kernel_write(file, data, bytes, NULL); > > I think the thread here is the same thing, but you've found it in > autofs... > https://lore.kernel.org/lkml/CAHk-=wgj=mKeN-EfV5tKwJNeHPLG0dybq+R5ZyGuc4WeUnqcmA@mail.gmail.com/ Indeed. Thanks, missed that. Sven ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-10-16 5:44 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <yt9d1ri3nakg.fsf@linux.ibm.com>
2020-10-13 7:20 ` autofs crash with latest linux-next Christian Borntraeger
2020-10-14 7:15 ` Krzysztof Kozlowski
2020-10-15 19:28 ` Kees Cook
2020-10-15 19:58 ` Krzysztof Kozlowski
2020-10-16 5:44 ` Sven Schnelle
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).