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
Since actual hotplug notifications don't get disabled until
nouveau_display_fini() is called, all this will do is cause any hotplugs
that happen between this drm_kms_helper_poll_disable() call and the
actual hotplug disablement to potentially be dropped if ACPI isn't
around to help us.
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Cc: stable(a)vger.kernel.org
Cc: Lukas Wunner <lukas(a)wunner.de>
Cc: Karol Herbst <karolherbst(a)gmail.com>
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c
index c7ec86d6c3c9..5fdc1fbe2ee5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -835,7 +835,6 @@ nouveau_pmops_runtime_suspend(struct device *dev)
return -EBUSY;
}
- drm_kms_helper_poll_disable(drm_dev);
nouveau_switcheroo_optimus_dsm();
ret = nouveau_do_suspend(drm_dev, true);
pci_save_state(pdev);
--
2.17.1
Turns out this part is my fault for not noticing when reviewing
9a2eba337cace ("drm/nouveau: Fix drm poll_helper handling"). Currently
we call drm_kms_helper_poll_enable() from nouveau_display_hpd_work().
This makes basically no sense however, because that means we're calling
drm_kms_helper_poll_enable() every time we schedule the hotplug
detection work. This is also against the advice mentioned in
drm_kms_helper_poll_enable()'s documentation:
Note that calls to enable and disable polling must be strictly ordered,
which is automatically the case when they're only call from
suspend/resume callbacks.
Of course, hotplugs can't really be ordered. They could even happen
immediately after we called drm_kms_helper_poll_disable() in
nouveau_display_fini(), which can lead to all sorts of issues.
Additionally; enabling polling /after/ we call
drm_helper_hpd_irq_event() could also mean that we'd miss a hotplug
event anyway, since drm_helper_hpd_irq_event() wouldn't bother trying to
probe connectors so long as polling is disabled.
So; simply move this back into nouveau_display_init() again. The race
condition that both of these patches attempted to work around has
already been fixed properly in
d61a5c106351 ("drm/nouveau: Fix deadlock on runtime suspend")
Fixes: 9a2eba337cace ("drm/nouveau: Fix drm poll_helper handling")
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Cc: Lukas Wunner <lukas(a)wunner.de>
Cc: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Cc: stable(a)vger.kernel.org
---
drivers/gpu/drm/nouveau/nouveau_display.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c
index ec7861457b84..1d36ab5d4796 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -355,8 +355,6 @@ nouveau_display_hpd_work(struct work_struct *work)
pm_runtime_get_sync(drm->dev->dev);
drm_helper_hpd_irq_event(drm->dev);
- /* enable polling for external displays */
- drm_kms_helper_poll_enable(drm->dev);
pm_runtime_mark_last_busy(drm->dev->dev);
pm_runtime_put_sync(drm->dev->dev);
@@ -411,6 +409,11 @@ nouveau_display_init(struct drm_device *dev)
if (ret)
return ret;
+ /* enable connector detection and polling for connectors without HPD
+ * support
+ */
+ drm_kms_helper_poll_enable(dev);
+
/* enable hotplug interrupts */
drm_connector_list_iter_begin(dev, &conn_iter);
nouveau_for_each_non_mst_connector_iter(connector, &conn_iter) {
--
2.17.1
Hi Greg,
commit 92d34134193e ("jfs: Fix inconsistency between memory allocation and
ea_buf->max_size") fixes CVE-2018-12233. As far as I can see, the commit is
not in any stable releases. It applies to all stable releases at least as
far back as v4.4.y (and it builds unless I really messed up).
Copying author and committer in case there are any concerns. Otherwise,
please apply to stable releases.
Thanks,
Guenter