]> git.ipfire.org Git - thirdparty/libvirt.git/commit
util: Add magic number check for object validity
authorJohn Ferlan <jferlan@redhat.com>
Mon, 31 Jul 2017 22:58:55 +0000 (18:58 -0400)
committerJohn Ferlan <jferlan@redhat.com>
Tue, 15 Aug 2017 01:41:59 +0000 (21:41 -0400)
commitdfa0efbb770f88b5c134545c969f8d47f95e6de9
tree327ed30abde9c63d9a6cc70b391e183f1d740add
parent19f4395230e073c1a857be9b8d684aec998d5d7d
util: Add magic number check for object validity

The virObjectIsClass API has only ever checked object validity
based on if the @obj is not NULL and it was derived from some class.
While this has worked well in general, there is one additional
check that could be made prior to calling virClassIsDerivedFrom
which loops through the classes checking the magic number against
the klass expected magic number.

If by chance a non virObject is passed, rather than assuming the
void * @obj is a _virObject and thus offsetting to obj->klass,
obj->magic, and obj->parent, let's check that the void * @obj
has at least the "base part" of the magic number in the right
place and generate a more specific VIR_WARN message if not.

There are many consumers to virObjectIsClass, include the locking
primitives virObject{Lock|Unlock}, virObjectRWLock{Read|Write},
and virObjectRWUnlock. For those callers, the locking call will
not fail, but it also will not attempt a virMutex* call which
will "most likely" fail since the &obj->lock is used.

In order to avoid some possible future wrap on the 0xCAFExxxx
value, add a check during initialization that some new class
won't cause the wrap. Should be good for a few years at least!

It is still left up to the caller to handle the failed API calls
just as it would be if it passed a NULL opaque pointer anyobj.
src/util/virobject.c