From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: David Howells <dhowells@redhat.com>
Cc: torvalds@linux-foundation.org, stable@vger.kernel.org,
Vasily Averin <vvs@virtuozzo.com>,
keyrings@vger.kernel.org, linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] keys: Fix proc_keys_next to increase position index
Date: Thu, 16 Apr 2020 16:54:32 +0000 [thread overview]
Message-ID: <20200416165432.GA199110@linux.intel.com> (raw)
In-Reply-To: <158689639664.3925765.4549426529245164675.stgit@warthog.procyon.org.uk>
On Tue, Apr 14, 2020 at 09:33:16PM +0100, David Howells wrote:
> From: Vasily Averin <vvs@virtuozzo.com>
>
> If seq_file .next function does not change position index,
> read after some lseek can generate unexpected output:
>
> $ dd if=/proc/keys bs=1 # full usual output
> 0f6bfdf5 I--Q--- 2 perm 3f010000 1000 1000 user 4af2f79ab8848d0a: 740
> 1fb91b32 I--Q--- 3 perm 1f3f0000 1000 65534 keyring _uid.1000: 2
> 27589480 I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16
> 2f33ab67 I--Q--- 152 perm 3f030000 0 0 keyring _ses: 2
> 33f1d8fa I--Q--- 4 perm 3f030000 1000 1000 keyring _ses: 1
> 3d427fda I--Q--- 2 perm 3f010000 1000 1000 user 69ec44aec7678e5a: 740
> 3ead4096 I--Q--- 1 perm 1f3f0000 1000 65534 keyring _uid_ses.1000: 1
> 521+0 records in
> 521+0 records out
> 521 bytes copied, 0,00123769 s, 421 kB/s
>
> $ dd if=/proc/keys bsP0 skip=1 # read after lseek in middle of last line
> dd: /proc/keys: cannot skip to specified offset
> g _uid_ses.1000: 1 <<<< end of last line
> 3ead4096 I--Q--- 1 perm 1f3f0000 1000 65534 keyring _uid_ses.1000: 1
> <<<< and whole last line again
> 0+1 records in
> 0+1 records out
> 97 bytes copied, 0,000135035 s, 718 kB/s
>
> $ dd if=/proc/keys bs\x1000 skip=1 # read after lseek beyond end of file
> dd: /proc/keys: cannot skip to specified offset
> 3ead4096 I--Q--- 1 perm 1f3f0000 1000 65534 keyring _uid_ses.1000: 1
> <<<< generates last line
> 0+1 records in
> 0+1 records out
> 76 bytes copied, 0,000119981 s, 633 kB/s
>
> See https://bugzilla.kernel.org/show_bug.cgi?id 6283
>
> Cc: stable@vger.kernel.org
# 4.19.x
> Fixes: 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code ...")
> Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
> Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
/Jarkko
WARNING: multiple messages have this Message-ID (diff)
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: David Howells <dhowells@redhat.com>
Cc: torvalds@linux-foundation.org, stable@vger.kernel.org,
Vasily Averin <vvs@virtuozzo.com>,
keyrings@vger.kernel.org, linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] keys: Fix proc_keys_next to increase position index
Date: Thu, 16 Apr 2020 19:54:32 +0300 [thread overview]
Message-ID: <20200416165432.GA199110@linux.intel.com> (raw)
In-Reply-To: <158689639664.3925765.4549426529245164675.stgit@warthog.procyon.org.uk>
On Tue, Apr 14, 2020 at 09:33:16PM +0100, David Howells wrote:
> From: Vasily Averin <vvs@virtuozzo.com>
>
> If seq_file .next function does not change position index,
> read after some lseek can generate unexpected output:
>
> $ dd if=/proc/keys bs=1 # full usual output
> 0f6bfdf5 I--Q--- 2 perm 3f010000 1000 1000 user 4af2f79ab8848d0a: 740
> 1fb91b32 I--Q--- 3 perm 1f3f0000 1000 65534 keyring _uid.1000: 2
> 27589480 I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16
> 2f33ab67 I--Q--- 152 perm 3f030000 0 0 keyring _ses: 2
> 33f1d8fa I--Q--- 4 perm 3f030000 1000 1000 keyring _ses: 1
> 3d427fda I--Q--- 2 perm 3f010000 1000 1000 user 69ec44aec7678e5a: 740
> 3ead4096 I--Q--- 1 perm 1f3f0000 1000 65534 keyring _uid_ses.1000: 1
> 521+0 records in
> 521+0 records out
> 521 bytes copied, 0,00123769 s, 421 kB/s
>
> $ dd if=/proc/keys bs=500 skip=1 # read after lseek in middle of last line
> dd: /proc/keys: cannot skip to specified offset
> g _uid_ses.1000: 1 <<<< end of last line
> 3ead4096 I--Q--- 1 perm 1f3f0000 1000 65534 keyring _uid_ses.1000: 1
> <<<< and whole last line again
> 0+1 records in
> 0+1 records out
> 97 bytes copied, 0,000135035 s, 718 kB/s
>
> $ dd if=/proc/keys bs=1000 skip=1 # read after lseek beyond end of file
> dd: /proc/keys: cannot skip to specified offset
> 3ead4096 I--Q--- 1 perm 1f3f0000 1000 65534 keyring _uid_ses.1000: 1
> <<<< generates last line
> 0+1 records in
> 0+1 records out
> 76 bytes copied, 0,000119981 s, 633 kB/s
>
> See https://bugzilla.kernel.org/show_bug.cgi?id=206283
>
> Cc: stable@vger.kernel.org
# 4.19.x
> Fixes: 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code ...")
> Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
> Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
/Jarkko
next prev parent reply other threads:[~2020-04-16 16:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-14 15:01 [PATCH] keys: Fix proc_keys_next to increase position index David Howells
2020-04-14 19:36 ` Jarkko Sakkinen
2020-04-14 20:33 ` David Howells
2020-04-14 20:33 ` David Howells
2020-04-16 16:54 ` Jarkko Sakkinen [this message]
2020-04-16 16:54 ` Jarkko Sakkinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200416165432.GA199110@linux.intel.com \
--to=jarkko.sakkinen@linux.intel.com \
--cc=dhowells@redhat.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=vvs@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.