netdev - Re: [PATCH net-next] eth: fbnic: fix ubsan complaints about OOB accesses

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250709171138.5da9df21@kernel.org>
Date: Wed, 9 Jul 2025 17:11:38 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jacob Keller <jacob.e.keller@...el.com>
Cc: <davem@...emloft.net>, <netdev@...r.kernel.org>, <edumazet@...gle.com>,
 <pabeni@...hat.com>, <andrew+netdev@...n.ch>, <horms@...nel.org>, Alexander
 Duyck <alexanderduyck@...com>, <lee@...ger.us>
Subject: Re: [PATCH net-next] eth: fbnic: fix ubsan complaints about OOB
 accesses

On Wed, 9 Jul 2025 14:23:11 -0700 Jacob Keller wrote:
> >  		head = list_first_entry(&log->entries, typeof(*head), list);
> > -		entry = (struct fbnic_fw_log_entry *)&head->msg[head->len + 1];   
> 
> I am guessing that UBSAN gets info about the hint for the length of the
> msg, via the counted_by annotation in the structure? Then it realizes
> that this is too large. Strictly taking address of a value doesn't
> actually directly access the memory... However, you then later access
> the value via the entry variable.. Perhaps UBSAN is complaining about that?

Could be.. The splat includes the line info for the line whether entry
is computed, but maybe that's just a nicety and the detection is done
at access time..