Change:
let e_alloc = cx.expr_or_init(e); let e_alloc = if let ExprKind::AddrOf(_, _, inner_expr) = e_alloc.kind { inner_expr } else { e_alloc }; <ins> // if the current expr looks like this `&mut expr[index]` then just looking // at `expr[index]` won't give us the underlying allocation, so we just skip it if let ExprKind::Index(..) = e_alloc.kind { return None; } </ins> let alloc_ty = cx.typeck_results().node_type(e_alloc.hir_id); // if we do not find it we bail out, as this may not be UB

Discussion:
Starting with rustc 1.78.0 (because of ) this produces the following <preerror: casting references to a bigger memory layout than the backing allocation is undefined behavior, even if the reference is unused -- | 5 | let a1 = &mut array[offset]; | ------------- backing allocation comes from here 6 | let a2 = a1 as mut u8; 7 | let a3 = a2 as mut u64; | -------------- casting happend here 8 | unsafe { 9 mask); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: casting from (1 bytes) to (8 bytes) = note: on by default </prePerhaps I'm missing something but this is not undefined behavior as far as I can tell. The lint is wrong about the backing allocation and I suspect the false warning is downstream from that?
Under the memory model checked by Miri by default, a is not permitted to access more than the one byte it points to, even if you got it from a larger object. Reborrowing to a reference type shrinks the allowed access range. Use instead to obtain a pointer that is valid to write to the correct region. would also be valid, as that region contains the correct bytes, but it's less precise about its intent. label -regression-from-stable-to-stable -C-bug -I-prioritize +C-discussion
Miri also agrees that the code as written contains undefined behavior, in the top right of the page select "Tools Miri" to run and you'll see that it says that there's undefined behavior. The important bit from the error message is that the code is trying to access (the intended 8 bytes), but the pointer does not have permission for that range, only (the first byte).
I think that the lint's wording should be changed though, "backing allocation" is not precise and does not correctly describe what it's detecting. cc label +A-diagnostics +D-papercut
Your comment and the lint are misleading. There is no accepted memory model. And the lint message is pointing to code which does not create an allocation, so at best the lint has grabbed the wrong span. If this lint is supposed to engage in provenance-based reasoning, it would need to indicate that. Otherwise it is simply buggy.

True, "the current" is not quite right. "The memory model currently checked by Miri by default" is perhaps a better wording for what I wanted to say, I will edit my comment. Agreed that the lint is definitely sketchy wording at best, and I'm suspicious of its implementation given the incorrect wording.
The lint is not supposed to engage in "provenance-based reasoning", it is just supposed to peel all the reference/raw pointer casting until it finds an allocation, and then it should compare the size of type and report an error if the target is bigger than the source. Nothing else, nothing more. I tried describing the intent of the change in So as correctly mentions it, nothing in this code creates an "allocation", so I think the lint shouldn't have fired here. (whenever there is actual UB or not is irrelevant here)