We were able to determine that only one table in the database in question had not had it's statistics updated. We did that by running the following
select object_name (i.id)as objectname,i.name as indexname,i.origfillfactor,i.rowcnt,i.rowmodctr ,STATS_DATE(i.id, i.indid) as ix_Statistics_Date,o.instrig,o.updtrig,o.deltrig,o.seltrig
from sysindexes i INNER JOIN dbo.sysobjects o ON i.id = o.id
where rowcnt >1000 and i.name not like'sys%'and object_name(i.id)not like'sys%'
order by objectname desc
So we ran the update statistics on just the table in question. And we were able to replicate the scenario in question as it was still waiting and not finishing. So then knowing the session ID of my waiting process I took a look at the locks table
select * from sys.dm_tran_locks
Looking at the results I found a different session ID associated with the Object_ID of my table in question. I was able to then go kill that session ID and the update statistics finished no problem.
What I think happened here was that a user left a program open that had the exclusive lock on my table, and perhaps that along with auto statistics in sync mode may have caused a log jam when doing our full scan update stats.