On 5/24/2024 7:47 PM, Greg KH wrote: > On Fri, May 24, 2024 at 05:08:06PM +0800, quic_zijuhu wrote: >> On 5/24/2024 2:56 PM, Greg KH wrote: >>> On Fri, May 24, 2024 at 01:34:49PM +0800, quic_zijuhu wrote: >>>> On 5/24/2024 1:21 PM, Greg KH wrote: >>>>> On Fri, May 24, 2024 at 01:15:01PM +0800, quic_zijuhu wrote: >>>>>> On 5/24/2024 12:33 PM, Greg KH wrote: >>>>>>> On Fri, May 24, 2024 at 12:20:03PM +0800, Zijun Hu wrote: >>>>>>>> zap_modalias_env() wrongly calculates size of memory block >>>>>>>> to move, so maybe cause OOB memory access issue, fixed by >>>>>>>> correcting size to memmove. >>>>>>> >>>>>>> "maybe" or "does"? That's a big difference :) >>>>>>> >>>>>> i found this issue by reading code instead of really meeting this issue. >>>>>> this issue should be prone to happen if there are more than 1 other >>>>>> environment vars. >>>>> >>>>> But does it? Given that we have loads of memory checkers, and I haven't >>>>> ever seen any report of any overrun, it would be nice to be sure. >>>>> >>>> yes. if @env includes env vairable MODALIAS and more than one other env >>>> vairables. then (env->buflen - len) must be greater that actual size of >>>> "target block" shown previously, so the OOB issue must happen. >>> >>> Then why are none of the tools that we have for catching out-of-bound >>> issues triggered here? Are the tools broken or is this really just not >>> ever happening? It would be good to figure that out... >>> >> don't know why. perhaps, need to report our case to expert of tools. > > Try running them yourself and see! i find out the reason why the OOB issue is difficult to be observed. the reason is that MODALIAS is the last variable added by most of drivers by accident, and it skips the obvious wrong logic within zap_modalias_env(). you maybe run below command to confirm the reason. grep -l -r MODALIAS drivers/ | xargs grep add_uevent_var
