Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 15 Jun 2023 08:04:18 +0200
From:   Greg KH <gregkh@linuxfoundation.org>
To:     Xia Fukun <xiafukun@huawei.com>
Cc:     prajnoha@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7] kobject: Fix global-out-of-bounds in
 kobject_action_type()
Message-ID: <2023061554-defective-islamist-fab5@gregkh>
References: <20230518091614.137522-1-xiafukun@huawei.com>
 <86c6040d-17ab-fb01-2b75-717d82ba9345@huawei.com>
 <2023061444-latticed-discuss-fa70@gregkh>
 <c8e7106c-872f-4d18-f4d8-de4c450fc587@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <c8e7106c-872f-4d18-f4d8-de4c450fc587@huawei.com>
Precedence: bulk

On Thu, Jun 15, 2023 at 09:43:34AM +0800, Xia Fukun wrote:
> 
> On 2023/6/15 4:09, Greg KH wrote:
> 
> > 
> > How did you test it?  How have you verified that the previous failures
> > were caught this time?
> > 
> 
> My testing method is to apply the patch, compile the kernel image,
> and start the QEMU virtual machine. Then compile and execute the code
> mentioned in the patch that triggers out-of-bounds issues.
> 
> In addition, the following operations will be performed to verify the
> functions mentioned by Peter Rajnoha <prajnoha@redhat.com>:
> 
> # echo "add fe4d7c9d-b8c6-4a70-9ef1-3d8a58d18eed A=1 B=abc" >
> /sys/block/ram0/uevent
> 
> # udevadm monitor --kernel --env
> monitor will print the received events for:
> KERNEL - the kernel uevent
> 
> KERNEL[189.376386] add      /devices/virtual/block/ram0 (block)
> ACTION=add
> DEVPATH=/devices/virtual/block/ram0
> SUBSYSTEM=block
> SYNTH_UUID=fe4d7c9d-b8c6-4a70-9ef1-3d8a58d18eed
> SYNTH_ARG_A=1
> SYNTH_ARG_B=abc
> DEVNAME=/dev/ram0
> DEVTYPE=disk
> DISKSEQ=14
> SEQNUM=3781
> MAJOR=1
> MINOR=0

So you have not run this on any real systems?  Please try doing that
(boot your laptop, your server, your server farm, etc.) with it and do a
lot of testing that way.

To only use qemu means it has not really been tested at all, which now
explains why you didn't find the previous problems with this patch
series as this is a kernel path that is HIGHLY dependent on the hardware
involved (i.e. it wants real hardware, not emulated ones.)

thanks,

greg k-h