This bug was fixed in the package qtwebkit-opensource-src -
5.212.0~alpha4-14

---------------
qtwebkit-opensource-src (5.212.0~alpha4-14) unstable; urgency=medium

  * debian/patches/jscore_big_endian.diff: Fix segmentation fault on s390x
    and potentially other 64-bit big endian systems (LP: #1951470).
    Thanks Andreas Krebbel for the patch and Frank Heimes for the initial
    debdiff!
  * Update debian/source/lintian-overrides for Lintian 2.109.

 -- Dmitry Shachnev <mity...@debian.org>  Wed, 24 Nov 2021 22:27:08
+0300

** Changed in: qtwebkit-opensource-src (Ubuntu Jammy)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to qtwebkit-opensource-src in
Ubuntu.
https://bugs.launchpad.net/bugs/1951470

Title:
  webkit javascript segmentation fault

Status in Ubuntu on IBM z Systems:
  In Progress
Status in qtwebkit-opensource-src package in Ubuntu:
  Fix Released
Status in qtwebkit-opensource-src source package in Focal:
  In Progress
Status in qtwebkit-opensource-src source package in Hirsute:
  In Progress
Status in qtwebkit-opensource-src source package in Impish:
  In Progress
Status in qtwebkit-opensource-src source package in Jammy:
  Fix Released

Bug description:
  SRU Justification:

  [Impact]

   * WebKit Javascript engine is causing a segmentation fault on big
  endian (s390x) systems.

   * This happens for example when transferring an html to a pdf file
  using wkhtmltopdf.

   * The fix is relatively simple with changing loadisFromInstruction to 
loadpFromInstruction
     in macro getProperty(slow), which solves this unpleasant situation.

   * The JIT ocde is 32bit (even on 64bit systems),
     hence is crucial to make sure the lower part of a 64bit value is taken on 
big endian systems.

  [Test Plan]

   * Testing is very straight forward by following these steps:

   * install the following packages (incl. their dependencies):
     $ sudo apt install libqt5webkit5 wkhtmltopdf

   * create an html file like this:
     $ vi index.html
     $ cat index.html
     <!doctype html>
     <html lang="de">
       <head>
       </head>
     
       <body>
         <script src="min.js"></script>
       </body>
     </html>

   * create a JavaScript file like this:
     $ vi min.js
     $ cat min.js
     var i = Math.max

   * call wkhtmltopdf to process the local files:
     $ wkhtmltopdf --enable-local-file-access index.html test.pdf

   * if it's broken one gets this output:
     Loading page (1/2)
     Segmentation fault (core dumped)                             ] 50%
     and no pdf file was generated:
     $ ls *.pdf
     ls: cannot access '*.pdf': No such file or directory

   * in case it's fixed one gets this output:
     Loading page (1/2)
     Printing pages (2/2)                                               
     Done                                                           
     and a pdf file was generated and in placed in the current directory (with 
more than 0 bytes size):
     $ ls -l ./*.pdf
     -rw-rw-r-- 1 ubuntu ubuntu 1339 Nov 24 11:48 ./test.pdf

  [Where problems could occur]

   * While this issue only affects big endian systems (like s390x),
     a bad fix may have an impact on little endian systems, too
     for example in case the wrong function got used in the macro.

   * But loadpFromInstruction is known to work for LE and BE systems;

   * and on top cross-architecture builds were done:
     https://launchpad.net/~fheimes/+archive/ubuntu/lp1951470

   * and tested on s390x (if the fix works) and on non-s390x (regression
  testing).

   * The changes are otherwise very limited, just:
         macro getProperty(slow)
     -    loadisFromInstruction(6, t1)
     +    loadpFromInstruction(6, t1)
     hence I think there is not much more to say.

  [Other Info]
   
   * The maintainer of the Debian packages (Dmitry Shachnev)
     is going to add this to the Debian package, too.

   * This issue affects Ubuntu jammy, impish, hirsute and focal - SRUs
  are ongoing.

   * The issue does not occur with the very latest upstream version anymore,
     and was fixed in a similar way as part of a commit
     that fixes numerous other CLoop issues on top:
     "Fix all CLoop JSC test failures (including some LLInt bugs due to recent 
bytecode format change)."
     commit 3fdde71c7d95d758a61fcbc4c58168616794c102

  __________

  == Comment: #0 - Andreas Krebbel <andreas.kreb...@de.ibm.com> - 2021-11-15 
09:29:44 ==
  ---Problem Description---
  Segmentation fault from WebKit Javascript engine

  Contact Information = andreas.kreb...@de.ibm.com

  ---uname output---
  Linux 193438490afd 5.8.15-301.fc33.s390x #1 SMP Thu Oct 15 15:55:57 UTC 2020 
s390x s390x s390x GNU/Linux

  Machine Type = IBM Z

  ---Debugger---
  A debugger is not configured

  ---Steps to Reproduce---
   index.html:
  <!doctype html>
  <html lang="de">
    <head>
    </head>

    <body>
      <script src="min.js"></script>
    </body>
  </html>

  min.js:
  var i = Math.max

  wkhtmltopdf index.html test.pdf
  QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
  Loading page (1/2)
  Segmentation fault (core dumped)                             ] 17%

  Userspace tool common name: wkhtmltopdf

  The userspace tool has the following bit modes: 64

  Userspace rpm: libqt5webkit5

  Userspace tool obtained from project website:  na

  *Additional Instructions for andreas.kreb...@de.ibm.com:
  -Attach ltrace and strace of userspace application.

  == Comment: #1 - Andreas Krebbel <andreas.kreb...@de.ibm.com> - 2021-11-15 
09:44:04 ==
  In CodeBlock.cpp the code preparing the operands of op_get_from_scope writes 
the property offset as pointer size (hence 64 bit) value:

  2141: instructions[i + 6].u.pointer =
  reinterpret_cast<void*>(op.operand);

  while the same slot is accessed later by the jitted code as 32 bit
  integer:

  macro getProperty(slow)
      loadisFromInstruction(6, t1)

  This fails on big endian targets since the integer access takes the
  higher part of the 64 bit value.

  Changing:

  macro getProperty(slow)
      loadisFromInstruction(6, t1)

  to

  macro getProperty(slow)
      loadpFromInstruction(6, t1)

  in llint/LowLevelInterpreter64.asm fixes the problem for me.

  I could not reproduce the problem on Ubuntu 20.10. In upstream webkit
  the problem got fixed as a side effect of a larger change but in the
  end quite similar to the change I'm proposing. The value resides
  somewhere else now but it is accessed as 64 bit value in getProperty:

  macro getProperty()
          loadp OpGetFromScope::Metadata::m_operand[t5], t1

  If you have the jsc binary from the webkit package available the
  problem can be reproduced with just 'jsc -e "i=Math.min"'

  == Comment: #2 - Andreas Krebbel <andreas.kreb...@de.ibm.com> -
  2021-11-15 09:49:55 ==

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1951470/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to