Control: tag -1 +moreinfo
Control: severity -1 normal
On Thu, Mar 24, 2022 at 04:00:23AM +0000, Olly Betts wrote:
> On Tue, Mar 22, 2022 at 06:56:23PM +0800, Jieyong Ma @ tdhxkj.com wrote:
> > Backtraces:
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x0000000000449515 in vAnalyseSummaryInfo (aucBuffer=0x6928f0 "t\001") at
> > summary.c:225
> > 225 switch (tPropID) {
>
> That seems a surprising line to segfault on as there's no dereference
> happening. Maybe optimisation has lead to misleading debug line numbers
> though.
>
> > (gdb) bt
> > #0 0x0000000000449515 in vAnalyseSummaryInfo (aucBuffer=0x6928f0 "t\001")
> > at summary.c:225
> > #1 vSetSummaryInfoOLE (pFile=0x68f2e0, pFile@entry=0x37,
> > pPPS=0x7fffffffbb10, pPPS@entry=0x68f2e0, aulBBD=0x68fb00,
> > aulBBD@entry=0x7fffffffbb80, tBBDLen=55, tBBDLen@entry=37,
> > aulSBD=aulSBD@entry=0x68fe80, tSBDLen=tSBDLen@entry=2)
> > at summary.c:628
> > #2 0x0000000000449bcf in vSet8SummaryInfo (pFile=0xff7f013c,
> > pFile@entry=0x68f2e0, pPPS=0x692a08, pPPS@entry=0x7fffffffbb10, aulBBD=0xb,
> > aulBBD@entry=0x68fb00, tBBDLen=10, tBBDLen@entry=55, aulSBD=0x692820,
> > aulSBD@entry=0x68fe80,
> > tSBDLen=29113347658312010, tSBDLen@entry=2, aucHeader=0x2 <error:
> > Cannot access memory at address 0x2>) at summary.c:686
> > #3 0x0000000000442126 in vGetPropertyInfo (pFile=pFile@entry=0x68f2e0,
> > pPPS=0x7fffffffbb10, pPPS@entry=0x7fffffffbb00,
> > aulBBD=aulBBD@entry=0x68fb00, tBBDLen=<optimized out>, tBBDLen@entry=55,
> > aulSBD=0x68fe80, aulSBD@entry=0x68fb00,
> > tSBDLen=2, tSBDLen@entry=0, aucHeader=0x7fffffffbb80 "\354\245\301",
> > iWordVersion=8) at properties.c:145
> > #4 0x0000000000458464 in iInitDocumentOLE (pFile=<optimized out>,
> > pFile@entry=0x68f2e0, lFilesize=<optimized out>, lFilesize@entry=28672) at
> > wordole.c:792
> > #5 0x00000000004552fb in iInitDocument (pFile=<optimized out>,
> > pFile@entry=0x68f2e0, lFilesize=<optimized out>, lFilesize@entry=28672) at
> > wordlib.c:325
> > #6 0x000000000044ce1f in bWordDecryptor (pFile=pFile@entry=0x68f2e0,
> > lFilesize=lFilesize@entry=28672, pDiag=0x68fac0) at word2text.c:665
> > #7 0x0000000000403ef3 in bProcessFile (szFilename=<optimized out>) at
> > main_u.c:214
> > #8 main (argc=2, argv=0x7fffffffe558) at main_u.c:310
> >
> > Ref: https://bugzilla.redhat.com/show_bug.cgi?id=2064638
>
> "Red Hat Bugzilla – Bug Access Denied"
I still can't access this bug report.
I assume that's where `vAnalyseSummaryInfo.poc.doc` can be found (you
didn't attach it to this bug report), so all I have to go on is the
backtrace which points to a line where there's no dereference.
There aren't any patches in Fedora that we don't have an equivalent of,
except for antiword-0.32-fix-flags.patch which isn't relevant to us:
https://src.fedoraproject.org/rpms/antiword/tree/rawhide
There doesn't seem to be a CVE for this (only ones from 2005 and 2014):
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=antiword
So as it stands, I don't see I can do anything useful with your report.
> There's no active upstream for antiword so someone needs to come up with
> a patch. If someone already has that'd be helpful (and better for the
> various Linux distros to all use the same fix than each come up with
> their own).
This is also very much still true.
Tagging appropriately. I've lowered the severity since failing to
process a single example file is not "a bug which has a major effect on
the usability of a package, without rendering it completely unusable to
everyone".
As best I can make out this is a segfault while reading, so there
doesn't seem there's a security implication either.
Cheers,
Olly
