kernel-packages team mailing list archive

[John Johansen <john.johansen@xxxxxxxxxxxxx>]

** Changed in: linux (Ubuntu Utopic)
       Status: New => Fix Committed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-armadaxp in Ubuntu.
https://bugs.launchpad.net/bugs/1335313

Title:
  CVE-2014-4608

Status in “linux” package in Ubuntu:
  Fix Committed
Status in “linux-armadaxp” package in Ubuntu:
  Invalid
Status in “linux-ec2” package in Ubuntu:
  Invalid
Status in “linux-fsl-imx51” package in Ubuntu:
  Invalid
Status in “linux-lts-backport-maverick” package in Ubuntu:
  New
Status in “linux-lts-backport-natty” package in Ubuntu:
  New
Status in “linux-lts-quantal” package in Ubuntu:
  Invalid
Status in “linux-lts-raring” package in Ubuntu:
  Invalid
Status in “linux-lts-saucy” package in Ubuntu:
  Invalid
Status in “linux-mvl-dove” package in Ubuntu:
  Invalid
Status in “linux-ti-omap4” package in Ubuntu:
  Invalid
Status in “linux” source package in Lucid:
  New
Status in “linux-armadaxp” source package in Lucid:
  Invalid
Status in “linux-ec2” source package in Lucid:
  New
Status in “linux-fsl-imx51” source package in Lucid:
  Invalid
Status in “linux-lts-backport-maverick” source package in Lucid:
  New
Status in “linux-lts-backport-natty” source package in Lucid:
  New
Status in “linux-lts-quantal” source package in Lucid:
  Invalid
Status in “linux-lts-raring” source package in Lucid:
  Invalid
Status in “linux-lts-saucy” source package in Lucid:
  Invalid
Status in “linux-mvl-dove” source package in Lucid:
  Invalid
Status in “linux-ti-omap4” source package in Lucid:
  Invalid
Status in “linux” source package in Precise:
  New
Status in “linux-armadaxp” source package in Precise:
  New
Status in “linux-ec2” source package in Precise:
  Invalid
Status in “linux-fsl-imx51” source package in Precise:
  Invalid
Status in “linux-lts-backport-maverick” source package in Precise:
  New
Status in “linux-lts-backport-natty” source package in Precise:
  New
Status in “linux-lts-quantal” source package in Precise:
  New
Status in “linux-lts-raring” source package in Precise:
  New
Status in “linux-lts-saucy” source package in Precise:
  New
Status in “linux-mvl-dove” source package in Precise:
  Invalid
Status in “linux-ti-omap4” source package in Precise:
  New
Status in “linux” source package in Saucy:
  New
Status in “linux-armadaxp” source package in Saucy:
  Invalid
Status in “linux-ec2” source package in Saucy:
  Invalid
Status in “linux-fsl-imx51” source package in Saucy:
  Invalid
Status in “linux-lts-backport-maverick” source package in Saucy:
  New
Status in “linux-lts-backport-natty” source package in Saucy:
  New
Status in “linux-lts-quantal” source package in Saucy:
  Invalid
Status in “linux-lts-raring” source package in Saucy:
  Invalid
Status in “linux-lts-saucy” source package in Saucy:
  Invalid
Status in “linux-mvl-dove” source package in Saucy:
  Invalid
Status in “linux-ti-omap4” source package in Saucy:
  New
Status in “linux” source package in Trusty:
  New
Status in “linux-armadaxp” source package in Trusty:
  Invalid
Status in “linux-ec2” source package in Trusty:
  Invalid
Status in “linux-fsl-imx51” source package in Trusty:
  Invalid
Status in “linux-lts-backport-maverick” source package in Trusty:
  New
Status in “linux-lts-backport-natty” source package in Trusty:
  New
Status in “linux-lts-quantal” source package in Trusty:
  Invalid
Status in “linux-lts-raring” source package in Trusty:
  Invalid
Status in “linux-lts-saucy” source package in Trusty:
  Invalid
Status in “linux-mvl-dove” source package in Trusty:
  Invalid
Status in “linux-ti-omap4” source package in Trusty:
  Invalid
Status in “linux” source package in Utopic:
  Fix Committed
Status in “linux-armadaxp” source package in Utopic:
  Invalid
Status in “linux-ec2” source package in Utopic:
  Invalid
Status in “linux-fsl-imx51” source package in Utopic:
  Invalid
Status in “linux-lts-backport-maverick” source package in Utopic:
  New
Status in “linux-lts-backport-natty” source package in Utopic:
  New
Status in “linux-lts-quantal” source package in Utopic:
  Invalid
Status in “linux-lts-raring” source package in Utopic:
  Invalid
Status in “linux-lts-saucy” source package in Utopic:
  Invalid
Status in “linux-mvl-dove” source package in Utopic:
  Invalid
Status in “linux-ti-omap4” source package in Utopic:
  Invalid

Bug description:
  All versions of the Linux kernel (3x/2x) with LZO support (lib/lzo)
  that set the HAVE_EFFICIENT_UNALIGNED_ACCESS configuration option.
  Currently, this seems to include PowerPC and i386. Vulnerability
  Tested:         - Via btrfs     - Stand alone Functions Affected:
  lib/lzo/lzo1x_decompress_safe.c:lzo1x_decompress_safe Criticality
  Reasoning --------------------- While some variants of this LZO
  algorithm flaw result in Remote Code Execution (RCE), it is unlikely
  that the Linux kernel variant can. This is due to the fact that
  control of the memory region that is overwritten can not be controlled
  in a fashion that will result in the overwrite of objects critical to
  the flow of execution. However, it may be possible to overwrite
  "business logic" data in certain circumstances, by corrupting adjacent
  objects in memory. Linux's guard pages should mitigate this, however.
  Because RCE is impractical, Object Over Write (OOM) is only practical
  in constrained scenarios (read: impractical), and DoS is practical,
  the criticality level of this issue should be defined as Moderate.
  Furthermore, a Moderate definition is needed because of the use of LZO
  in btrfs, and the potential use of LZO in networking, opening up the
  potential for remote instrumentation of this vulnerability. It is
  notable that SuSE recently reported that they will start using btrfs
  by default later this year. Lastly, only certain platforms are
  affected, decreasing impact. Vulnerability Description
  ------------------------- An integer overflow can occur when
  processing any variant of a "literal run" in the lzo1x_decompress_safe
  function. Each of these three locations is subject to an integer
  overflow when processing zero bytes. The following code depicts how
  the size of the literal array is generated:                        if
  (likely(state == 0)) {                                if (unlikely(t
  == 0)) {                                        while (unlikely(*ip ==
  0)) {                                                t += 255;
  ip++;                                                NEED_IP(1);
  }                                        t += 15 + *ip++;
  }                                t += 3; As long as a zero byte (0x00)
  is encountered, the variable 't' will be incremented by 255. Using
  approximately sixteen megabytes of zeros, 't' will accumulate to a
  maximum unsigned integer value on a 32bit architecture. In combination
  with the following code, the value of 't' will overflow:
  copy_literal_run: #if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
  if (likely(HAVE_IP(t + 15) && HAVE_OP(t + 15))) {
  const unsigned char *ie = ip + t;
  unsigned char *oe = op + t;                                        do
  {                                                COPY8(op, ip);
  op += 8;                                                ip += 8;
  COPY8(op, ip);                                                op += 8;
  ip += 8;                                        } while (ip < ie);
  ip = ie;                                        op = oe; The HAVE_OP()
  check will always pass in this case, because the size check within the
  macro will evaluate based on the overflown integer, not the value of
  't'. This exposes the code that copies literals to memory corruption.
  An interesting side effect of the vulnerable code shown above is that
  the value of 'op' can point to a region of memory just before the
  start of 'out'. It should be noted that the following code
  unintentionally saves all other architectures from exposure: #endif
  {                                        NEED_OP(t);
  NEED_IP(t + 3);                                        do {
  *op++ = *ip++;                                        } while (--t >
  0);                                } NEED_OP() correctly tests the
  value of 't' here, disallowing the potential for overflow. It should
  be noted that if 't' is a 64bit integer, the overflow is still
  possible, but impractical. An overflow would require so much input
  data that an attack would obviously be infeasible even on modern
  computers.

  Break-Fix: 64c70b1cf43de158282bc1675918d503e5b15cc1
  206a81c18401c0cde6e579164f752c4b147324ce

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1335313/+subscriptions