The Linux BTT implementation assumes that log entries will never have the 'zero' flag set, and indeed it never sets that flag for log entries itself. However, the UEFI spec is ambiguous on the exact format of the LBA field of a log entry, specifically as to whether it should include the additional flag bits or not. While a zero bit doesn't make sense in the context of a log entry, other BTT implementations might still have it set. If an implementation does happen to have it set, we would happily read it in as the next block to write to for writes. Since a high bit is set, it pushes the block number out of the range of an 'arena', and we fail such a write with an EIO. Follow the robustness principle, and tolerate such implementations by stripping out the zero flag when populating the free list during initialization. Cc: Dan Williams <dan.j.williams(a)intel.com&gt; Reported-by: Dexuan Cui <decui(a)microsoft.com&gt; Reported-by: Pedro d'Aquino Filocre F S Barbuda <pbarbuda(a)microsoft.com&gt; Tested-by: Dexuan Cui <decui(a)microsoft.com&gt; Signed-off-by: Vishal Verma <vishal.l.verma(a)intel.com&gt; --- drivers/nvdimm/btt.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/nvdimm/btt.c b/drivers/nvdimm/btt.c index b123b0dcf274..1c5447ac1e39 100644 --- a/drivers/nvdimm/btt.c +++ b/drivers/nvdimm/btt.c @@ -562,13 +562,15 @@ static int btt_freelist_init(struct arena_info *arena) /* sub points to the next one to be overwritten */ arena->freelist[i].sub = 1 - new; arena->freelist[i].seq = nd_inc_seq(le32_to_cpu(log_new.seq)); - arena->freelist[i].block = le32_to_cpu(log_new.old_map); + arena->freelist[i].block = + le32_to_cpu(ent_lba(log_new.old_map)); /* * FIXME: if error clearing fails during init, we want to make * the BTT read-only */ if (ent_e_flag(log_new.old_map)) { + set_e_flag(arena->freelist[i].block); ret = arena_clear_freelist_error(arena, i); if (ret) dev_err_ratelimited(to_dev(arena), -- 2.20.1