Hi, All
Sorry, I am following the instructions in
Documentation/networking/netdev-FAQ.txt to send out this mail,
if I was wrong or there are more things I need to do, please let me know.
After investigated on some failures of the android VtsKernelNetTest module test,
I found that without the change of "ipv4+ipv6: Make INET*_ESP select
CRYPTO_ECHAINIV",
the config of CRYPTO_ECHAINIV will be generated as m by default in the
.config file,
which needs more module loading process to be done.
But with the 4.9 and 4.14 kernels which have the change,
CRYPTO_ECHAINIV will be generated as y by default in the .config file.
We could set config of CRYPTO_ECHAINIV to y explicitly to generated
the correct .config file,
but having the change of "ipv4+ipv6: Make INET*_ESP select CRYPTO_ECHAINIV"
cherry picked into the 4.4 stable kernel looks more like the right solution.
The commit id for that change is 32b6170ca59ccf07d0e394561e54b2cd9726038c,
it's already in 4.9 and 4.14 kernels, like here:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/net…https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/net…
Could you please help to check if we could have
32b6170ca59ccf07d0e394561e54b2cd9726038c in the 4.4 stable kernel?
The patch is here:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/patch/net?…
Thanks in advance!
--
Best Regards,
Yongqin Liu
We hit the BUG() report at include/linux/scatterlist.h:144!
The callback is as bellow:
=> verity_work
=> verity_hash_for_block
=> verity_verify_level
=> verity_hash
=> verity_hash_update
=> sg_init_one
=> sg_set_buf
More debug shows the root cause. When creating dufio client it
uses the __vmalloc() to allocate the buffer data for the reserved
dm_buffer. The buffer that allocated by the __vmalloc() is invalid
according to the __virt_addr_valid().
Mostly the reserved dm_buffer is not touched. But occasionally
it might fail to allocate the dm_buffer data when we try to
allocate in the __alloc_buffer_wait_no_callback(). Then it has
to take the reserved dm_buffer for usage. Finally it reports the
BUG() as virt_addr_valid() detects the buffer data address is invalid.
The patch is to adjust the reserved buffer for dm-verity-target. We
allocated two dm_buffers into the reserved buffers list when creating
the buffer interface. The first dm_buffer in the reserved buffer list
is allocated by the __vmalloc(), it's not used after that. The second
dm_buffer in the reserved buffer list is allocated by the
__get_free_pages() which can be consumed after that.
Signed-off-by: xiao jin <jin.xiao(a)intel.com>
---
drivers/md/dm-bufio.c | 4 ++--
drivers/md/dm-verity-target.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/md/dm-bufio.c b/drivers/md/dm-bufio.c
index dc385b7..3b7ca5e 100644
--- a/drivers/md/dm-bufio.c
+++ b/drivers/md/dm-bufio.c
@@ -841,7 +841,7 @@ static struct dm_buffer *__alloc_buffer_wait_no_callback(struct dm_bufio_client
tried_noio_alloc = true;
}
- if (!list_empty(&c->reserved_buffers)) {
+ if (!c->need_reserved_buffers) {
b = list_entry(c->reserved_buffers.next,
struct dm_buffer, lru_list);
list_del(&b->lru_list);
@@ -1701,7 +1701,7 @@ struct dm_bufio_client *dm_bufio_client_create(struct block_device *bdev, unsign
goto bad;
}
- while (c->need_reserved_buffers) {
+ if (list_empty(&c->reserved_buffers)) {
struct dm_buffer *b = alloc_buffer(c, GFP_KERNEL);
if (!b) {
diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c
index 12decdbd7..40c66fc 100644
--- a/drivers/md/dm-verity-target.c
+++ b/drivers/md/dm-verity-target.c
@@ -1107,7 +1107,7 @@ static int verity_ctr(struct dm_target *ti, unsigned argc, char **argv)
v->hash_blocks = hash_position;
v->bufio = dm_bufio_client_create(v->hash_dev->bdev,
- 1 << v->hash_dev_block_bits, 1, sizeof(struct buffer_aux),
+ 1 << v->hash_dev_block_bits, 2, sizeof(struct buffer_aux),
dm_bufio_alloc_callback, NULL);
if (IS_ERR(v->bufio)) {
ti->error = "Cannot initialize dm-bufio";
--
2.7.4
The patch titled
Subject: zram-remove-bd_cap_synchronous_io-with-writeback-feature-v2
has been added to the -mm tree. Its filename is
zram-remove-bd_cap_synchronous_io-with-writeback-feature-v2.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/zram-remove-bd_cap_synchronous_io-…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/zram-remove-bd_cap_synchronous_io-…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Minchan Kim <minchan(a)kernel.org>
Subject: zram-remove-bd_cap_synchronous_io-with-writeback-feature-v2
- description correction - Andrew
- add comment about removing BDI_CAP_SYNCHRONOUS_IO
Link: https://lore.kernel.org/lkml/0516ae2d-b0fd-92c5-aa92-112ba7bd32fc@contabo.d…
Link: http://lkml.kernel.org/r/20180802051112.86174-1-minchan@kernel.org
Link: http://lkml.kernel.org/r/20180805233722.217347-1-minchan@kernel.org
Signed-off-by: Minchan Kim <minchan(a)kernel.org>
Reported-by: Tino Lehnig <tino.lehnig(a)contabo.de>
Tested-by: Tino Lehnig <tino.lehnig(a)contabo.de>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work(a)gmail.com>
Cc: Jens Axboe <axboe(a)kernel.dk>
Cc: <stable(a)vger.kernel.org> [4.15+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
diff -puN drivers/block/zram/zram_drv.c~zram-remove-bd_cap_synchronous_io-with-writeback-feature-v2 drivers/block/zram/zram_drv.c
--- a/drivers/block/zram/zram_drv.c~zram-remove-bd_cap_synchronous_io-with-writeback-feature-v2
+++ a/drivers/block/zram/zram_drv.c
@@ -401,6 +401,16 @@ static ssize_t backing_dev_store(struct
zram->backing_dev = backing_dev;
zram->bitmap = bitmap;
zram->nr_pages = nr_pages;
+ /*
+ * With writeback feature, zram does asynchronous IO so it's no longer
+ * synchronous device so let's remove synchronous io flag. Othewise,
+ * upper layer(e.g., swap) could wait IO completion rather than
+ * (submit and return), which will cause system sluggish.
+ * Furthermore, when the IO function returns(e.g., swap_readpage),
+ * upper layer expects IO was done so it could deallocate the page
+ * freely but in fact, IO is going on so finally could cause
+ * use-after-free when the IO is really done.
+ */
zram->disk->queue->backing_dev_info->capabilities &=
~BDI_CAP_SYNCHRONOUS_IO;
up_write(&zram->init_lock);
_
Patches currently in -mm which might be from minchan(a)kernel.org are
zram-remove-bd_cap_synchronous_io-with-writeback-feature.patch
zram-remove-bd_cap_synchronous_io-with-writeback-feature-v2.patch
Hi Greg,
I conformed that a patch of CVE-2018-13095 not applied at v4.14.60.
Could you please apply a patch for 4.14-stable ?
CVE-2018-13095
Upstream commit 23fcb3340d033d9f081e21e6c12c2db7eaa541d3
References
https://nvd.nist.gov/vuln/detail/CVE-2018-13095
Regards,
Yuki Machida