Skip to content
  1. Sep 05, 2022
    • Xin Xiong's avatar
      xfrm: fix refcount leak in __xfrm_policy_check() · 18e6b6e2
      Xin Xiong authored
      [ Upstream commit 9c9cb23e ]
      
      The issue happens on an error path in __xfrm_policy_check(). When the
      fetching process of the object `pols[1]` fails, the function simply
      returns 0, forgetting to decrement the reference count of `pols[0]`,
      which is incremented earlier by either xfrm_sk_policy_lookup() or
      xfrm_policy_lookup(). This may result in memory leaks.
      
      Fix it by decreasing the reference count of `pols[0]` in that path.
      
      Fixes: 134b0fc5
      
       ("IPsec: propagate security module errors up from flow_cache_lookup")
      Signed-off-by: default avatarXin Xiong <xiongx18@fudan.edu.cn>
      Signed-off-by: default avatarXin Tan <tanxin.ctf@gmail.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      18e6b6e2
    • Helge Deller's avatar
      parisc: Fix exception handler for fldw and fstw instructions · 555666fd
      Helge Deller authored
      commit 7ae1f550
      
       upstream.
      
      The exception handler is broken for unaligned memory acceses with fldw
      and fstw instructions, because it trashes or uses randomly some other
      floating point register than the one specified in the instruction word
      on loads and stores.
      
      The instruction "fldw 0(addr),%fr22L" (and the other fldw/fstw
      instructions) encode the target register (%fr22) in the rightmost 5 bits
      of the instruction word. The 7th rightmost bit of the instruction word
      defines if the left or right half of %fr22 should be used.
      
      While processing unaligned address accesses, the FR3() define is used to
      extract the offset into the local floating-point register set.  But the
      calculation in FR3() was buggy, so that for example instead of %fr22,
      register %fr12 [((22 * 2) & 0x1f) = 12] was used.
      
      This bug has been since forever in the parisc kernel and I wonder why it
      wasn't detected earlier. Interestingly I noticed this bug just because
      the libime debian package failed to build on *native* hardware, while it
      successfully built in qemu.
      
      This patch corrects the bitshift and masking calculation in FR3().
      
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      555666fd
  2. Aug 25, 2022