[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9ee60162-110b-1305-5a97-624de425d072@users.sourceforge.net>
Date: Mon, 3 Oct 2016 15:47:46 +0200
From: SF Markus Elfring <elfring@...rs.sourceforge.net>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: kvm@...r.kernel.org, linux-s390@...r.kernel.org,
Christian Bornträger <borntraeger@...ibm.com>,
Cornelia Huck <cornelia.huck@...ibm.com>,
David Hildenbrand <dahi@...ux.vnet.ibm.com>,
Heiko Carstens <heiko.carstens@...ibm.com>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
LKML <linux-kernel@...r.kernel.org>,
kernel-janitors@...r.kernel.org,
Julia Lawall <julia.lawall@...6.fr>,
Walter Harms <wharms@....de>
Subject: Re: [PATCH v2 2/2] KVM: s390: Use memdup_user() rather than
duplicating code
>> Did you notice the check "IS_ERR(bp_data)" and the corresponding reaction
>> in this update suggestion?
>
> Yes, but bp_data may still be a valid (as in "not an error") value.
Thanks for your constructive feedback.
> Your commit a1708a2eaded836b ("KVM: s390: Improve determination of sizes in
> kvm_s390_import_bp_data()") made the code more robust, as kmalloc_array() ha
> a builtin overflow check, and will return NULL if overflow is detected.
> However, commit 0624a8eb82efd58e ("KVM: s390: Use memdup_user() rather than
> duplicating code") dropped that safety net again.
* How much are you concerned about the shown software evolution around
multiplications for memory allocations?
* Does there really a probability remain that an inappropriate product
would be calculated here (as the situation was before my two update steps
for this software module)?
* Can it be that you are looking for a variant of a function like "memdup_user"
where values can be passed as separate parameters "count" and "size" so that
the needed multiplication and corresponding overflow check would be performed
together as desired?
Regards,
Markus
Powered by blists - more mailing lists