On 06.11.2019 23:38, Christos Zoulas wrote:
> On Nov 6, 11:17pm, n...@gmx.com (Kamil Rytarowski) wrote:
> -- Subject: Re: CVS commit: src/sys/kern
> | Technically, I think that this is a real UB.
> | 
> |
> | A pointer to an object type may be converted to a pointer to a
> | different object type. If the resulting pointer is not correctly
> | aligned for the referenced type, the behavior is undefined.
> Then you are right. I guess the rationale for the above is that
> ... pauses to think ... Dereferencing the new object with the
> different type can fail if the original pointer was unaligned?
> I don't see how.

I recall a similar UB in tmux that is simpler to illustrate.

struct screen                   *s = &data->screen;

/// if data is NULL -> return

format_add(ft, "selection_present", "%d", s->sel.flag);

This triggered UBSan as we syntactically dereferenced a NULL pointer,
which is UB. The intention was to set s = data + offsetof(data, screen)
and very compiler optimizes it to do the right thing without real

Similarly from a syntactical point of view we first dereference
dlp->d_magic, and next ask for its address &(). This is how I understand
the GCC behavior here.

This is certainly very sensitive behavior of the sanitzier, but it can
catch real bugs. It helped to diagnoze at least a single UVM crash (we
had crash reports from ASan and UBSan).

> | I agree that this is appeasing the sanitizer.
> Yes, on that we agree.
> christos


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to