Skip to content

No longer crash 64 bit Adobe Acrobat / Reader when rendering a virtualBuffer for PDF content#13852

Merged
seanbudd merged 8 commits into
masterfrom
i12920
Jul 15, 2022
Merged

No longer crash 64 bit Adobe Acrobat / Reader when rendering a virtualBuffer for PDF content#13852
seanbudd merged 8 commits into
masterfrom
i12920

Conversation

@michaelDCurran

Copy link
Copy Markdown
Member

Link to issue number:

Fixes #12920

Summary of the issue:

Adobe Acrobat / Reader 64 bit crashes when NVDA renders a virtualBuffer for PDF content.
There are two reasons for this:

  1. Adobe's IAccID custom interface has been changed so that specifically on 64 bit builds, the ID argument is now 64 bit wide instead of 32 bit. This meant that NVDA was using the wrong data type and wrong call signature for IAccID::get_accID, and therefore Acrobat / Reader was trying to write a 64 bit value in to the space that could only hold 32 bits, causing a buffer overrun.
  2. Adobe Acrobat / Reader's accID values, including the MSAA child IDs used for IAccessible::get_accChild and AccessibleObjectFromEvent were 64 bit wide, though MSAA only supports 32 bit values. This would cause invalid and truncated values to be used for child IDs, in many cases causing a crash.

Adobe has addressed point 2 in Adobe Acrobat / Reader beta versions and will be in a stable build in the near future.
But NVDA needs to address point 1 in its own code.

Description of user facing changes

Using a version of Adobe Acrobat / Reader with the required fixes on adobe's side, along with this PR in NVDA, the crash is avoided.

Description of development approach

miscDeps has been updated to contain the newest version of acrobatAccess.idl from the Adobe Acrobat SDK.
The adobeAcrobat vbufBackend getAccID method has been changed to fetch the out param of IAccID::get_accID with a LONG_PRT which will be 64 bit wide on 64 bit Acrobat / Reader, and 32 bit wide on 32 bit Acrobat / Reader. The value is then static casted to long when returned. As Acrobat always uses 32 bit accID vlaues, no information will be lost in the conversion.

Testing strategy:

Opened multiple pdf documents in Adobe Acrobat / Reader while running NVDA. Ensured that Acrobat / Reader did not crash and that the pdf could be read with the arrow keys.

Known issues with pull request:

None known.

Change log entries:

New features
Changes
Bug fixes

Code Review Checklist:

  • Pull Request description:
    • description is up to date
    • change log entries
  • Testing:
    • Unit tests
    • System (end to end) tests
    • Manual testing
  • API is compatible with existing add-ons.
  • Documentation:
    • User Documentation
    • Developer / Technical Documentation
    • Context sensitive help for GUI changes
  • UX of all users considered:
    • Speech
    • Braille
    • Low Vision
    • Different web browsers
    • Localization in other languages / culture than English

…nglong on 64 bit and long on 32 bit, therefore use a LONG_PTR to fetch the put param and static cast it to long on return. Internally, Acrobat only deals with 32 bit accIDs so will never overflow. But this change is necessary otherwise windows COM will try writing past the end of the out param, causing a crash.
@michaelDCurran

Copy link
Copy Markdown
Member Author

Although this requires an Acrobat / Reader with fixes to fully avoid the crash, this can still be merged to master safely. It however will not make the crash better until the fixes is available on the adobe side also.

@michaelDCurran michaelDCurran marked this pull request as ready for review June 28, 2022 09:10
@michaelDCurran michaelDCurran requested a review from a team as a code owner June 28, 2022 09:10
@michaelDCurran michaelDCurran requested a review from seanbudd June 28, 2022 09:10
Comment thread nvdaHelper/vbufBackends/adobeAcrobat/adobeAcrobat.cpp Outdated
michaelDCurran and others added 2 commits June 29, 2022 17:05
Co-authored-by: Sean Budd <sean@nvaccess.org>
@CyrilleB79

Copy link
Copy Markdown
Contributor

@michaelDCurran wrote:

Although this requires an Acrobat / Reader with fixes to fully avoid the crash, this can still be merged to master safely. It however will not make the crash better until the fixes is available on the adobe side also.

But @seanbudd put the "blocked/needs-external-fix" label.

If an early (immediate) merge of this PR is done, this would allow to have the issue fixed as ssoon as Adobe releases a fix for it. On the contrary, if Adobe's fix is expected to merge this PR, the issue will be fixed only when the next NVDA release is available, what takes more time.

Can the reason of the "blocked/needs-external-fix" label be clarified or checked? Thanks.

@seanbudd seanbudd added merge-early Merge Early in a developer cycle release/blocking this issue blocks the milestone release and removed merge-early Merge Early in a developer cycle labels Jul 5, 2022
@seanbudd

seanbudd commented Jul 5, 2022

Copy link
Copy Markdown
Member

@CyrilleB79 - it is safe to merge, but without an Adobe build to test with, there is no way to be certain that the issue is fixed.
There is also no urgency to merge this without a beta/public Adobe build, at least until we branch for 2022.3.
I have added another label to reflect the fact that this will go into 2022.3.

@seanbudd seanbudd added this to the 2022.3 milestone Jul 5, 2022
@OzancanKaratas

Copy link
Copy Markdown
Collaborator

Adobe has already released a bug fix. Please check for updates in your product. I tested it and this pull request works as expected. See the release notes here.

@seanbudd

seanbudd commented Jul 6, 2022

Copy link
Copy Markdown
Member

@OzancanKaratas I have no trouble using that build of Adobe Reader with NVDA 2022.2beta2,
i.e. #12920 is already fixed on Adobe's end for me using stable NVDA.
I believe the issue that this PR fixes is waiting on a future Adobe build, I will need to confirm.

@seanbudd

Copy link
Copy Markdown
Member

@OzancanKaratas - do you have the same experience as me?
Are you, or anyone else, still experiencing the crash using the latest Adobe reader and the latest beta/stable/alpha NVDA?

@k-kolev1985

Copy link
Copy Markdown
Contributor

I can still reproduce this.

Test environment:

  • Operating system: Windows 11 Pro version 21H2 (build 22000.739), 64-bit, in Bulgarian with all locale settings set to "Bulgarian".
  • NVDA version: alpha-25815,8a237d40, installed.
  • Adobe Acrobat DC version: 2022.001.20142, 64-bit, in english.

@seanbudd

Copy link
Copy Markdown
Member

Thanks @k-kolev1985: does this PR build fix the issue?

@k-kolev1985

Copy link
Copy Markdown
Contributor

Yes, it does.

@OzancanKaratas

Copy link
Copy Markdown
Collaborator

@seanbudd, I approved the build in this pull request as it fixed the issue. But if I don't use the build here, I still reproduce the problem.

@seanbudd seanbudd requested a review from feerrenrut July 13, 2022 05:08
Comment thread nvdaHelper/vbufBackends/adobeAcrobat/adobeAcrobat.cpp Outdated
Comment thread nvdaHelper/vbufBackends/adobeAcrobat/adobeAcrobat.cpp Outdated
Co-authored-by: Reef Turner <feerrenrut@users.noreply.github.com>
@seanbudd seanbudd merged commit d6a193a into master Jul 15, 2022
@seanbudd seanbudd deleted the i12920 branch July 15, 2022 07:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

release/blocking this issue blocks the milestone release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

NVDA does not work with Adobe reader DC 64 bit

7 participants