[REGRESSION] nvme: code command_id with a genctr for use-after-free validation crashes apple T2 SSD
Orlando Chamberlain
redecorating at protonmail.com
Sat Sep 25 06:10:42 PDT 2021
Commit e7006de6c238 causes the SSD controller on Apple T2 computers to crash
and prevents linux from booting.
This commit implemented a counter that is stored within the NVMe command_id,
however this counter makes the command_id higher than normal, causing a panic
on the T2 security chip that functions as the SSD controller, which then
causes the system to power off after a few seconds.
This was reported on bugzilla here:
https://bugzilla.kernel.org/show_bug.cgi?id=214509 but it was not originally
classified as NVMe (when the report was created it was unknown what was
causing it), so I don't know if it notified the NVMe mailing list when it
was later reclassified to NVMe. Sorry if you've already seen this issue.
The T2 security chip (which is the SSD) has this line in its crash log (the
rest of this log is in an attachment on the bugzilla report):
panic(cpu 1 caller 0xfffffff028d884ec): ANS2 Recoverable Panic - assert failed: [7447]:command id out of range error (cid = 4120), status_reg: 0x2000 - Null(2)
This is the entry in lspci -nn for the ssd:
04:00.0 Mass storage controller [0180]: Apple Inc. ANS2 NVMe Controller [106b:2005] (rev 01)
This commit was included in 5.14.6 and backported to 5.10.67, but does not
occur in 5.14.5 and 5.10.66. I am on a MacBookPro16,1, the crash has been
reproduced on a MacBookPro16,2 as well. I have been able to reproduce on Arch
Linux with vanilla kernel 5.10.67 (others have gotten it on 5.14.6) with no
DKMS modules, and I bisected it to that commit
(e7006de6c23803799be000a5dcce4d916a36541a).
I've tried to modify the genctr so that it is in the other side of the
command_id (which I thought might make the command_id's lower) with the patch
below, but it did not prevent the crash.
Regards,
Orlando Chamberlain
--- a/drivers/nvme/host/nvme.h
+++ b/drivers/nvme/host/nvme.h
@@ -489,17 +489,20 @@ struct nvme_ctrl_ops {
/*
* nvme command_id is constructed as such:
- * | xxxx | xxxxxxxxxxxx |
- * gen request tag
- */
+ * | xxxxxxxxxxxx | xxxx |
+ * request tag gen
+ *
+ * The gen is at the end as the SSD in Apple T2 Computers
+ * crashes when the command_id is too high.
+*/
#define nvme_genctr_mask(gen) (gen & 0xf)
-#define nvme_cid_install_genctr(gen) (nvme_genctr_mask(gen) << 12)
-#define nvme_genctr_from_cid(cid) ((cid & 0xf000) >> 12)
-#define nvme_tag_from_cid(cid) (cid & 0xfff)
+#define nvme_cid_install_genctr(gen) (nvme_genctr_mask(gen))
+#define nvme_genctr_from_cid(cid) ((cid & 0x000f))
+#define nvme_tag_from_cid(cid) ((cid & 0xfff0) >> 4)
static inline u16 nvme_cid(struct request *rq)
{
- return nvme_cid_install_genctr(nvme_req(rq)->genctr) | rq->tag;
+ return nvme_cid_install_genctr(nvme_req(rq)->genctr) | (rq->tag << 4);
}
static inline struct request *nvme_find_rq(struct blk_mq_tags *tags,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - redecorating at protonmail.com - 0xEE1BCCD7.asc
Type: application/pgp-keys
Size: 1873 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-nvme/attachments/20210925/645801c0/attachment-0001.bin>
More information about the Linux-nvme
mailing list