linux-kernel - Re: [PATCH v7] kobject: Fix global-out-of-bounds in kobject_action

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]

Date:   Thu, 15 Jun 2023 08:04:18 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Xia Fukun <xiafukun@...wei.com>
Cc:     prajnoha@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7] kobject: Fix global-out-of-bounds in
 kobject_action_type()

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@...hat.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