Messages in this thread | | | Subject | Re: [PATCH] libceph, ceph: potential dereference of null pointer | From | Xiubo Li <> | Date | Thu, 9 Dec 2021 20:59:13 +0800 |
| |
On 12/9/21 7:20 PM, Jeff Layton wrote: > On Thu, 2021-12-09 at 10:50 +0800, Jiasheng Jiang wrote: >> The return value of kzalloc() needs to be checked. >> To avoid use of null pointer in case of the failure of alloc. >> >> Fixes: 3d14c5d2b6e1 ("ceph: factor out libceph from Ceph file system") >> Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> >> --- >> net/ceph/osd_client.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/net/ceph/osd_client.c b/net/ceph/osd_client.c >> index ff8624a7c964..3203e8a34370 100644 >> --- a/net/ceph/osd_client.c >> +++ b/net/ceph/osd_client.c >> @@ -1234,6 +1234,8 @@ static struct ceph_osd *create_osd(struct ceph_osd_client *osdc, int onum) >> WARN_ON(onum == CEPH_HOMELESS_OSD); >> >> osd = kzalloc(sizeof(*osd), GFP_NOIO | __GFP_NOFAIL); >> + if (!osd) >> + return NULL; >> osd_init(osd); >> osd->o_osdc = osdc; >> osd->o_osd = onum; > __GFP_NOFAIL should ensure that it never returns NULL, right?
Yeah, from the comment, it make no sense to test for failure here:
204 * %__GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller 205 * cannot handle allocation failures. The allocation could block 206 * indefinitely but will never return with failure. Testing for 207 * failure is pointless. 208 * New users should be evaluated carefully (and the flag should be 209 * used only when there is no reasonable failure policy) but it is 210 * definitely preferable to use the flag rather than opencode endless 211 * loop around allocator. 212 * Using this flag for costly allocations is _highly_ discouraged. 213 */
> Also, if you're going to fix this up to handle that error then you > probably also need to fix lookup_create_osd to handle a NULL return from > create_osd as well.
| |