On Thu, Feb 2, 2023 at 9:18 AM Kees Cook <keescook@xxxxxxxxxxxx> wrote: > On Wed, Feb 01, 2023 at 12:11:41AM -0800, John Stultz wrote: > > On Tue, Jan 31, 2023 at 11:36 PM Yongqin Liu <yongqin.liu@xxxxxxxxxx> wrote: > > > This change causes "Kernel panic - not syncing: BRK handler: Fatal exception" > > > for the android-mainline based hikey960 build, with this commit reverted, > > > there is no problem for the build to boot to the homescreen. > > > Not sure if you have any idea about it and give some suggestions. > > > > > > Here is part of the kernel panic log: ... > > Here as nr_sensors=1, we allocate only one structure for the array. > > But then below that, we modify two entries, writing past the valid > > array, and corrupting data when writing the second sensor values. > > > > data->sensor[0].id = HI3660_BIG_SENSOR; > > data->sensor[0].irq_name = "tsensor_a73"; > > data->sensor[0].data = data; > > > > data->sensor[1].id = HI3660_LITTLE_SENSOR; > > data->sensor[1].irq_name = "tsensor_a53"; > > data->sensor[1].data = data; > > > > I suspect nr_sensors needs to be set to 2. > > > > Nice work, Kees! > > Yay for compilers! :) Well, I know it's not trivial to make the compilers catch these things, so yay for you and others putting in all the effort on this as well. That said, making sense of the error message isn't completely trivial either. I've been seeing a few cases recently of some of the new compiler tooling (I pinged you earlier on a CFI one) causing errors that developers aren't really sure how to address. I know sometimes it's not easy to surface the errors with context to what was wrong, but at the risk of intense bike shedding, is there some way to provide something like "Likely array bounds error" instead of just "BRK handler: Fatal exception"? > Was a patch sent to fix this driver? I think YongQin is looking into it (either setting the nr_sensors value to 2 or dropping the second sensor access). thanks -john
