[Bug 206310] The vnic driver may lock an uninitialised mutex

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Sat Jan 16 12:31:47 UTC 2016


            Bug ID: 206310
           Summary: The vnic driver may lock an uninitialised mutex
           Product: Base System
           Version: 11.0-CURRENT
          Hardware: arm64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: Andrew at FreeBSD.org

If you configure the ThunderX vnic with iovctl -C, then before using it delete
the children the kernel will panic with  NULL pointer dereference in

The issue is nicvf_free_cmp_queue will attempt to lock it's mutex, however the
mutex may not have been initialised. The call to mtx_init is in
nicvf_init_cmp_queue, this seems to only be called when ioctl configures the

There is a second issue where, if nicvf_alloc_resources fails we could call
nicvf_free_cmp_queue where the queue_set may have not been initialised.

I would expect a correct solution will have either the nicvf_free_* functions
will handle being called on when the object they are freeing has not been
initialised, or they will not be called when this is the case.

The stacktrace is as follows.

b> bt
Tracing pid 9149 tid 100575 td 0xffffffc0540e8000
db_trace_self() at db_stack_trace+0xf0
         pc = 0xffffff80005af4e4  lr = 0xffffff8000072440
         sp = 0xffffff87ccb4ae90  fp = 0xffffff87ccb4aec0

db_stack_trace() at db_command+0x248
         pc = 0xffffff8000072440  lr = 0xffffff80000720cc
         sp = 0xffffff87ccb4aed0  fp = 0xffffff87ccb4afb0

db_command() at db_command_loop+0x60
         pc = 0xffffff80000720cc  lr = 0xffffff8000071e68
         sp = 0xffffff87ccb4afc0  fp = 0xffffff87ccb4afe0

db_command_loop() at db_trap+0xf0
         pc = 0xffffff8000071e68  lr = 0xffffff80000748fc
         sp = 0xffffff87ccb4aff0  fp = 0xffffff87ccb4b220

db_trap() at kdb_trap+0x180
         pc = 0xffffff80000748fc  lr = 0xffffff800030772c
         sp = 0xffffff87ccb4b230  fp = 0xffffff87ccb4b290

kdb_trap() at data_abort+0x17c
         pc = 0xffffff800030772c  lr = 0xffffff80005c2d38
         sp = 0xffffff87ccb4b2a0  fp = 0xffffff87ccb4b350

data_abort() at handle_el1h_sync+0x6c
         pc = 0xffffff80005c2d38  lr = 0xffffff80005b086c
         sp = 0xffffff87ccb4b360  fp = 0xffffff87ccb4b470

handle_el1h_sync() at __mtx_lock_sleep+0x70
         pc = 0xffffff80005b086c  lr = 0xffffff80002a2a08
         sp = 0xffffff87ccb4b480  fp = 0xffffff87ccb4b550

__mtx_lock_sleep() at nicvf_free_resources+0x37c
         pc = 0xffffff80002a2a08  lr = 0xffffff80005d059c
         sp = 0xffffff87ccb4b560  fp = 0xffffff87ccb4b5c0

nicvf_free_resources() at nicvf_config_data_transfer+0xa2c
         pc = 0xffffff80005d059c  lr = 0xffffff80005cfad0
         sp = 0xffffff87ccb4b5d0  fp = 0xffffff87ccb4b690

nicvf_config_data_transfer() at nicvf_stop_locked+0xc8
         pc = 0xffffff80005cfad0  lr = 0xffffff80005ceadc
         sp = 0xffffff87ccb4b6a0  fp = 0xffffff87ccb4b6d0

nicvf_stop_locked() at nicvf_detach+0x94
         pc = 0xffffff80005ceadc  lr = 0xffffff80005cda78
         sp = 0xffffff87ccb4b6e0  fp = 0xffffff87ccb4b700

You are receiving this mail because:
You are the assignee for the bug.

More information about the freebsd-bugs mailing list