Issue metadata
Sign in to add a comment
|
CVE-2018-5344 CrOS: Vulnerability reported in Linux kernel |
||||||||||||||||||||||
Issue descriptionVOMIT (go/vomit) has received an external vulnerability report for the Linux kernel. Advisory: CVE-2018-5344 Details: http://vomit.googleplex.com/advisory?id=CVE/CVE-2018-5344 CVSS severity score: 4.6/10.0 Description: In the Linux kernel through 4.14.13, drivers/block/loop.c mishandles lo_release serialization, which allows attackers to cause a denial of service (__lock_acquire use-after-free) or possibly have unspecified other impact. This bug was filed by http://go/vomit Please contact us at vomit-team@google.com if you need any assistance.
,
Feb 2 2018
,
Feb 3 2018
Upstream ae6650163 ("loop: fix concurrent lo_open/lo_release"). Needs to be applied to 4.4, 4.14, 3.8, 3.14, 3.10.
as access to disk->private_data is not guarded.
3.18 looks okay.
,
Feb 3 2018
,
Feb 3 2018
zsm@: Why not chromeos-3.18 ?
,
Feb 4 2018
,
Feb 5 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/93b52d2c7dd1b3e1b002bbceb971c67774b561a1 commit 93b52d2c7dd1b3e1b002bbceb971c67774b561a1 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Mon Feb 05 23:44:51 2018 BACKPORT: loop: fix concurrent lo_open/lo_release reports that KASAN can report a use-after-free in __lock_acquire. The reason is due to insufficient serialization in lo_release(), which will continue to use the loop device even after it has decremented the lo_refcnt to zero. In the meantime, another process can come in, open the loop device again as it is being shut down. Confusion ensues. BUG= chromium:808389 TEST=Build and run Change-Id: Iad871f952c3eda1ef8e6336876fa6d10062e35c6 Reported-by: <long7573@126.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> Conflicts: drivers/block/loop.c (return type of lo_release() changed; older kernels return an error) Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit ae6650163c66a7eff1acd6eb8b0f752dcfa8eba5) Reviewed-on: https://chromium-review.googlesource.com/900550 Reviewed-by: Zubin Mithra <zsm@chromium.org> Reviewed-by: Dylan Reid <dgreid@chromium.org> [modify] https://crrev.com/93b52d2c7dd1b3e1b002bbceb971c67774b561a1/drivers/block/loop.c
,
Feb 5 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/449fb59c3f484b68d0a64135b904d995d5b665de commit 449fb59c3f484b68d0a64135b904d995d5b665de Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Mon Feb 05 23:44:58 2018 UPSTREAM: loop: fix concurrent lo_open/lo_release reports that KASAN can report a use-after-free in __lock_acquire. The reason is due to insufficient serialization in lo_release(), which will continue to use the loop device even after it has decremented the lo_refcnt to zero. In the meantime, another process can come in, open the loop device again as it is being shut down. Confusion ensues. BUG= chromium:808389 TEST=Build and run Change-Id: Iad871f952c3eda1ef8e6336876fa6d10062e35c6 Reported-by: <long7573@126.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit ae6650163c66a7eff1acd6eb8b0f752dcfa8eba5) Reviewed-on: https://chromium-review.googlesource.com/900549 Reviewed-by: Zubin Mithra <zsm@chromium.org> Reviewed-by: Dylan Reid <dgreid@chromium.org> [modify] https://crrev.com/449fb59c3f484b68d0a64135b904d995d5b665de/drivers/block/loop.c
,
Feb 6 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/38d3ad5c9aed9d6b5758e6b9799020e3b09910cb commit 38d3ad5c9aed9d6b5758e6b9799020e3b09910cb Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Tue Feb 06 03:08:28 2018 UPSTREAM: loop: fix concurrent lo_open/lo_release reports that KASAN can report a use-after-free in __lock_acquire. The reason is due to insufficient serialization in lo_release(), which will continue to use the loop device even after it has decremented the lo_refcnt to zero. In the meantime, another process can come in, open the loop device again as it is being shut down. Confusion ensues. BUG= chromium:808389 TEST=Build and run Change-Id: Iad871f952c3eda1ef8e6336876fa6d10062e35c6 Reported-by: <long7573@126.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit ae6650163c66a7eff1acd6eb8b0f752dcfa8eba5) Reviewed-on: https://chromium-review.googlesource.com/900387 [modify] https://crrev.com/38d3ad5c9aed9d6b5758e6b9799020e3b09910cb/drivers/block/loop.c
,
Feb 6 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/73d3ce408f07c27118d5cd6fc456b2fa90e74b1c commit 73d3ce408f07c27118d5cd6fc456b2fa90e74b1c Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Tue Feb 06 03:08:35 2018 UPSTREAM: loop: fix concurrent lo_open/lo_release reports that KASAN can report a use-after-free in __lock_acquire. The reason is due to insufficient serialization in lo_release(), which will continue to use the loop device even after it has decremented the lo_refcnt to zero. In the meantime, another process can come in, open the loop device again as it is being shut down. Confusion ensues. BUG= chromium:808389 TEST=Build and run Change-Id: Iad871f952c3eda1ef8e6336876fa6d10062e35c6 Reported-by: <long7573@126.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit ae6650163c66a7eff1acd6eb8b0f752dcfa8eba5) Reviewed-on: https://chromium-review.googlesource.com/900386 [modify] https://crrev.com/73d3ce408f07c27118d5cd6fc456b2fa90e74b1c/drivers/block/loop.c
,
Feb 6 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/65afd2b87cfe957b847cf5a71c9e4bb1daa49790 commit 65afd2b87cfe957b847cf5a71c9e4bb1daa49790 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Tue Feb 06 07:06:00 2018 UPSTREAM: loop: fix concurrent lo_open/lo_release reports that KASAN can report a use-after-free in __lock_acquire. The reason is due to insufficient serialization in lo_release(), which will continue to use the loop device even after it has decremented the lo_refcnt to zero. In the meantime, another process can come in, open the loop device again as it is being shut down. Confusion ensues. BUG= chromium:808389 TEST=Build and run Change-Id: Iad871f952c3eda1ef8e6336876fa6d10062e35c6 Reported-by: <long7573@126.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit ae6650163c66a7eff1acd6eb8b0f752dcfa8eba5) Reviewed-on: https://chromium-review.googlesource.com/900388 [modify] https://crrev.com/65afd2b87cfe957b847cf5a71c9e4bb1daa49790/drivers/block/loop.c
,
Feb 6 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/7f6a437747fe5df1bf8499ddfa10be88a007fe2e commit 7f6a437747fe5df1bf8499ddfa10be88a007fe2e Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Tue Feb 06 07:05:53 2018 UPSTREAM: loop: fix concurrent lo_open/lo_release reports that KASAN can report a use-after-free in __lock_acquire. The reason is due to insufficient serialization in lo_release(), which will continue to use the loop device even after it has decremented the lo_refcnt to zero. In the meantime, another process can come in, open the loop device again as it is being shut down. Confusion ensues. BUG= chromium:808389 TEST=Build and run Change-Id: Iad871f952c3eda1ef8e6336876fa6d10062e35c6 Reported-by: <long7573@126.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit ae6650163c66a7eff1acd6eb8b0f752dcfa8eba5) Reviewed-on: https://chromium-review.googlesource.com/900389 [modify] https://crrev.com/7f6a437747fe5df1bf8499ddfa10be88a007fe2e/drivers/block/loop.c
,
Feb 6 2018
,
Feb 7 2018
Your change meets the bar and is auto-approved for M65. Please go ahead and merge the CL to branch 3325 manually. Please contact milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 7 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/c14fd63ae70effdf286caad6f423fcfe30f4dc47 commit c14fd63ae70effdf286caad6f423fcfe30f4dc47 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Wed Feb 07 09:16:41 2018 UPSTREAM: loop: fix concurrent lo_open/lo_release 范龙飞 reports that KASAN can report a use-after-free in __lock_acquire. The reason is due to insufficient serialization in lo_release(), which will continue to use the loop device even after it has decremented the lo_refcnt to zero. In the meantime, another process can come in, open the loop device again as it is being shut down. Confusion ensues. BUG= chromium:808389 TEST=Build and run Change-Id: Iad871f952c3eda1ef8e6336876fa6d10062e35c6 Reported-by: 范龙飞 <long7573@126.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit ae6650163c66a7eff1acd6eb8b0f752dcfa8eba5) Reviewed-on: https://chromium-review.googlesource.com/900825 [modify] https://crrev.com/c14fd63ae70effdf286caad6f423fcfe30f4dc47/drivers/block/loop.c
,
Feb 7 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/8112ab35bb7e6141caf6bd0c74583ae4359b6f38 commit 8112ab35bb7e6141caf6bd0c74583ae4359b6f38 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Wed Feb 07 09:16:44 2018 UPSTREAM: loop: fix concurrent lo_open/lo_release 范龙飞 reports that KASAN can report a use-after-free in __lock_acquire. The reason is due to insufficient serialization in lo_release(), which will continue to use the loop device even after it has decremented the lo_refcnt to zero. In the meantime, another process can come in, open the loop device again as it is being shut down. Confusion ensues. BUG= chromium:808389 TEST=Build and run Change-Id: Iad871f952c3eda1ef8e6336876fa6d10062e35c6 Reported-by: 范龙飞 <long7573@126.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit ae6650163c66a7eff1acd6eb8b0f752dcfa8eba5) Reviewed-on: https://chromium-review.googlesource.com/899860 [modify] https://crrev.com/8112ab35bb7e6141caf6bd0c74583ae4359b6f38/drivers/block/loop.c
,
Feb 7 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/39148e047b4f20084de6af608db18106389a0755 commit 39148e047b4f20084de6af608db18106389a0755 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Wed Feb 07 09:16:45 2018 UPSTREAM: loop: fix concurrent lo_open/lo_release 范龙飞 reports that KASAN can report a use-after-free in __lock_acquire. The reason is due to insufficient serialization in lo_release(), which will continue to use the loop device even after it has decremented the lo_refcnt to zero. In the meantime, another process can come in, open the loop device again as it is being shut down. Confusion ensues. BUG= chromium:808389 TEST=Build and run Change-Id: Iad871f952c3eda1ef8e6336876fa6d10062e35c6 Reported-by: 范龙飞 <long7573@126.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit ae6650163c66a7eff1acd6eb8b0f752dcfa8eba5) Reviewed-on: https://chromium-review.googlesource.com/900826 [modify] https://crrev.com/39148e047b4f20084de6af608db18106389a0755/drivers/block/loop.c
,
Feb 7 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/0af57028232950d60942416aaf577d301297bc48 commit 0af57028232950d60942416aaf577d301297bc48 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Wed Feb 07 09:16:55 2018 BACKPORT: loop: fix concurrent lo_open/lo_release 范龙飞 reports that KASAN can report a use-after-free in __lock_acquire. The reason is due to insufficient serialization in lo_release(), which will continue to use the loop device even after it has decremented the lo_refcnt to zero. In the meantime, another process can come in, open the loop device again as it is being shut down. Confusion ensues. BUG= chromium:808389 TEST=Build and run Change-Id: Iad871f952c3eda1ef8e6336876fa6d10062e35c6 Reported-by: 范龙飞 <long7573@126.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> Conflicts: drivers/block/loop.c (return type of lo_release() changed; older kernels return an error) Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit ae6650163c66a7eff1acd6eb8b0f752dcfa8eba5) Reviewed-on: https://chromium-review.googlesource.com/900827 [modify] https://crrev.com/0af57028232950d60942416aaf577d301297bc48/drivers/block/loop.c
,
Feb 7 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/e33b03ba1f588ffdf01e396f3d49695b7d176431 commit e33b03ba1f588ffdf01e396f3d49695b7d176431 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Wed Feb 07 09:16:57 2018 UPSTREAM: loop: fix concurrent lo_open/lo_release 范龙飞 reports that KASAN can report a use-after-free in __lock_acquire. The reason is due to insufficient serialization in lo_release(), which will continue to use the loop device even after it has decremented the lo_refcnt to zero. In the meantime, another process can come in, open the loop device again as it is being shut down. Confusion ensues. BUG= chromium:808389 TEST=Build and run Change-Id: Iad871f952c3eda1ef8e6336876fa6d10062e35c6 Reported-by: 范龙飞 <long7573@126.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit ae6650163c66a7eff1acd6eb8b0f752dcfa8eba5) Reviewed-on: https://chromium-review.googlesource.com/900824 [modify] https://crrev.com/e33b03ba1f588ffdf01e396f3d49695b7d176431/drivers/block/loop.c
,
Feb 7 2018
,
Feb 8 2018
,
May 16 2018
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by groeck@chromium.org
, Feb 2 2018Labels: Security_Severity-Medium M-65 Security_Impact-Stable Pri-1
Owner: zsm@chromium.org
Status: Assigned (was: Untriaged)