Merge tag 'v6.6.59' into for/openbmc/dev-6.6

This is the 6.6.59 stable release

xfrm: validate new SA's prefixlen using SA family when sel.family is unset

[ Upstream commit 3f0ab59e6537c6a8f9e1b355b48f9c05a76e8563 ]

This expands the validation introduced in commit 07bf7908950a

xfrm: validate new SA's prefixlen using SA family when sel.family is unset

[ Upstream commit 3f0ab59e6537c6a8f9e1b355b48f9c05a76e8563 ]

This expands the validation introduced in commit 07bf7908950a ("xfrm:
Validate address prefix lengths in the xfrm selector.")

syzbot created an SA with
usersa.sel.family = AF_UNSPEC
usersa.sel.prefixlen_s = 128
usersa.family = AF_INET

Because of the AF_UNSPEC selector, verify_newsa_info doesn't put
limits on prefixlen_{s,d}. But then copy_from_user_state sets
x->sel.family to usersa.family (AF_INET). Do the same conversion in
verify_newsa_info before validating prefixlen_{s,d}, since that's how
prefixlen is going to be used later on.

Reported-by: syzbot+cc39f136925517aed571@syzkaller.appspotmail.com
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Antony Antony <antony.antony@secunet.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

xfrm: fix one more kernel-infoleak in algo dumping

commit 6889cd2a93e1e3606b3f6e958aa0924e836de4d2 upstream.

During fuzz testing, the following issue was discovered:

BUG: KMSAN: kernel-infoleak in

xfrm: fix one more kernel-infoleak in algo dumping

commit 6889cd2a93e1e3606b3f6e958aa0924e836de4d2 upstream.

During fuzz testing, the following issue was discovered:

BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x598/0x2a30
_copy_to_iter+0x598/0x2a30
__skb_datagram_iter+0x168/0x1060
skb_copy_datagram_iter+0x5b/0x220
netlink_recvmsg+0x362/0x1700
sock_recvmsg+0x2dc/0x390
__sys_recvfrom+0x381/0x6d0
__x64_sys_recvfrom+0x130/0x200
x64_sys_call+0x32c8/0x3cc0
do_syscall_64+0xd8/0x1c0
entry_SYSCALL_64_after_hwframe+0x79/0x81

Uninit was stored to memory at:
copy_to_user_state_extra+0xcc1/0x1e00
dump_one_state+0x28c/0x5f0
xfrm_state_walk+0x548/0x11e0
xfrm_dump_sa+0x1e0/0x840
netlink_dump+0x943/0x1c40
__netlink_dump_start+0x746/0xdb0
xfrm_user_rcv_msg+0x429/0xc00
netlink_rcv_skb+0x613/0x780
xfrm_netlink_rcv+0x77/0xc0
netlink_unicast+0xe90/0x1280
netlink_sendmsg+0x126d/0x1490
__sock_sendmsg+0x332/0x3d0
____sys_sendmsg+0x863/0xc30
___sys_sendmsg+0x285/0x3e0
__x64_sys_sendmsg+0x2d6/0x560
x64_sys_call+0x1316/0x3cc0
do_syscall_64+0xd8/0x1c0
entry_SYSCALL_64_after_hwframe+0x79/0x81

Uninit was created at:
__kmalloc+0x571/0xd30
attach_auth+0x106/0x3e0
xfrm_add_sa+0x2aa0/0x4230
xfrm_user_rcv_msg+0x832/0xc00
netlink_rcv_skb+0x613/0x780
xfrm_netlink_rcv+0x77/0xc0
netlink_unicast+0xe90/0x1280
netlink_sendmsg+0x126d/0x1490
__sock_sendmsg+0x332/0x3d0
____sys_sendmsg+0x863/0xc30
___sys_sendmsg+0x285/0x3e0
__x64_sys_sendmsg+0x2d6/0x560
x64_sys_call+0x1316/0x3cc0
do_syscall_64+0xd8/0x1c0
entry_SYSCALL_64_after_hwframe+0x79/0x81

Bytes 328-379 of 732 are uninitialized
Memory access of size 732 starts at ffff88800e18e000
Data copied to user address 00007ff30f48aff0

CPU: 2 PID: 18167 Comm: syz-executor.0 Not tainted 6.8.11 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014

Fixes copying of xfrm algorithms where some random
data of the structure fields can end up in userspace.
Padding in structures may be filled with random (possibly sensitve)
data and should never be given directly to user-space.

A similar issue was resolved in the commit
8222d5910dae ("xfrm: Zero padding when dumping algos and encap")

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Fixes: c7a5899eb26e ("xfrm: redact SA secret with lockdown confidentiality")
Cc: stable@vger.kernel.org
Co-developed-by: Boris Tonofa <b.tonofa@ideco.ru>
Signed-off-by: Boris Tonofa <b.tonofa@ideco.ru>
Signed-off-by: Petr Vaganov <p.vaganov@ideco.ru>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

Merge tag 'v6.6.44' into for/openbmc/dev-6.6

This is the 6.6.44 stable release

xfrm: call xfrm_dev_policy_delete when kill policy

[ Upstream commit 89a2aefe4b084686c2ffc1ee939585111ea4fc0f ]

xfrm_policy_kill() is called at different places to delete xfrm
policy. It will call

xfrm: call xfrm_dev_policy_delete when kill policy

[ Upstream commit 89a2aefe4b084686c2ffc1ee939585111ea4fc0f ]

xfrm_policy_kill() is called at different places to delete xfrm
policy. It will call xfrm_pol_put(). But xfrm_dev_policy_delete() is
not called to free the policy offloaded to hardware.

The three commits cited here are to handle this issue by calling
xfrm_dev_policy_delete() outside xfrm_get_policy(). But they didn't
cover all the cases. An example, which is not handled for now, is
xfrm_policy_insert(). It is called when XFRM_MSG_UPDPOLICY request is
received. Old policy is replaced by new one, but the offloaded policy
is not deleted, so driver doesn't have the chance to release hardware
resources.

To resolve this issue for all cases, move xfrm_dev_policy_delete()
into xfrm_policy_kill(), so the offloaded policy can be deleted from
hardware when it is called, which avoids hardware resources leakage.

Fixes: 919e43fad516 ("xfrm: add an interface to offload policy")
Fixes: bf06fcf4be0f ("xfrm: add missed call to delete offloaded policies")
Fixes: 982c3aca8bac ("xfrm: delete offloaded policy")
Signed-off-by: Jianbo Liu <jianbol@nvidia.com>
Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

Merge tag 'v6.6.24' into dev-6.6

This is the 6.6.24 stable release

xfrm: Avoid clang fortify warning in copy_to_user_tmpl()

commit 1a807e46aa93ebad1dfbed4f82dc3bf779423a6e upstream.

After a couple recent changes in LLVM, there is a warning (or error with
CONFIG_WE

xfrm: Avoid clang fortify warning in copy_to_user_tmpl()

commit 1a807e46aa93ebad1dfbed4f82dc3bf779423a6e upstream.

After a couple recent changes in LLVM, there is a warning (or error with
CONFIG_WERROR=y or W=e) from the compile time fortify source routines,
specifically the memset() in copy_to_user_tmpl().

In file included from net/xfrm/xfrm_user.c:14:
...
include/linux/fortify-string.h:438:4: error: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
438 | __write_overflow_field(p_size_field, size);
| ^
1 error generated.

While ->xfrm_nr has been validated against XFRM_MAX_DEPTH when its value
is first assigned in copy_templates() by calling validate_tmpl() first
(so there should not be any issue in practice), LLVM/clang cannot really
deduce that across the boundaries of these functions. Without that
knowledge, it cannot assume that the loop stops before i is greater than
XFRM_MAX_DEPTH, which would indeed result a stack buffer overflow in the
memset().

To make the bounds of ->xfrm_nr clear to the compiler and add additional
defense in case copy_to_user_tmpl() is ever used in a path where
->xfrm_nr has not been properly validated against XFRM_MAX_DEPTH first,
add an explicit bound check and early return, which clears up the
warning.

Cc: stable@vger.kernel.org
Link: https://github.com/ClangBuiltLinux/linux/issues/1985
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

Merge drm/drm-fixes into drm-misc-fixes

Forwarding to v6.6-rc1.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

Merge branch 'next' into for-linus

Prepare input updates for 6.6 merge window.

BackMerge tag 'v6.5-rc7' into drm-next

Linux 6.5-rc7

This is needed for the CI stuff and the msm pull has fixes in it.

Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge commit b320441c04c9 ("Merge tag 'tty-6.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty") into tty-next

We need the serial-core fixes in here as well.

Signed-off-by: Greg Kr

Merge commit b320441c04c9 ("Merge tag 'tty-6.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty") into tty-next

We need the serial-core fixes in here as well.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

Cross-merge networking fixes after downstream PR.

Conflicts:

drivers/net/ethernet/sfc/tc.c
fa165e194997 ("sfc: don't unregister flo

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

Cross-merge networking fixes after downstream PR.

Conflicts:

drivers/net/ethernet/sfc/tc.c
fa165e194997 ("sfc: don't unregister flow_indr if it was never registered")
3bf969e88ada ("sfc: add MAE table machinery for conntrack table")
https://lore.kernel.org/all/20230818112159.7430e9b4@canb.auug.org.au/

No adjacent changes.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>

show more ...

Merge tag 'net-6.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

Pull networking fixes from Jakub Kicinski:
"Including fixes from ipsec and netfilter.

No known outstanding reg

Merge tag 'net-6.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

Pull networking fixes from Jakub Kicinski:
"Including fixes from ipsec and netfilter.

No known outstanding regressions.

Fixes to fixes:

- virtio-net: set queues after driver_ok, avoid a potential race
added by recent fix

- Revert "vlan: Fix VLAN 0 memory leak", it may lead to a warning
when VLAN 0 is registered explicitly

- nf_tables:
- fix false-positive lockdep splat in recent fixes
- don't fail inserts if duplicate has expired (fix test failures)
- fix races between garbage collection and netns dismantle

Current release - new code bugs:

- mlx5: Fix mlx5_cmd_update_root_ft() error flow

Previous releases - regressions:

- phy: fix IRQ-based wake-on-lan over hibernate / power off

Previous releases - always broken:

- sock: fix misuse of sk_under_memory_pressure() preventing system
from exiting global TCP memory pressure if a single cgroup is under
pressure

- fix the RTO timer retransmitting skb every 1ms if linear option is
enabled

- af_key: fix sadb_x_filter validation, amment netlink policy

- ipsec: fix slab-use-after-free in decode_session6()

- macb: in ZynqMP resume always configure PS GTR for non-wakeup
source

Misc:

- netfilter: set default timeout to 3 secs for sctp shutdown send and
recv state (from 300ms), align with protocol timers"

* tag 'net-6.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (49 commits)
ice: Block switchdev mode when ADQ is active and vice versa
qede: fix firmware halt over suspend and resume
net: do not allow gso_size to be set to GSO_BY_FRAGS
sock: Fix misuse of sk_under_memory_pressure()
sfc: don't fail probe if MAE/TC setup fails
sfc: don't unregister flow_indr if it was never registered
net: dsa: mv88e6xxx: Wait for EEPROM done before HW reset
net/mlx5: Fix mlx5_cmd_update_root_ft() error flow
net/mlx5e: XDP, Fix fifo overrun on XDP_REDIRECT
i40e: fix misleading debug logs
iavf: fix FDIR rule fields masks validation
ipv6: fix indentation of a config attribute
mailmap: add entries for Simon Horman
broadcom: b44: Use b44_writephy() return value
net: openvswitch: reject negative ifindex
team: Fix incorrect deletion of ETH_P_8021AD protocol vid from slaves
net: phy: broadcom: stub c45 read/write for 54810
netfilter: nft_dynset: disallow object maps
netfilter: nf_tables: GC transaction race with netns dismantle
netfilter: nf_tables: fix GC transaction races with netns and netlink event exit path
...

show more ...

Merge tag 'ipsec-2023-08-15' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec

Steffen Klassert says:

====================
1) Fix a slab-out-of-bounds read in xfrm_address_filter.

Merge tag 'ipsec-2023-08-15' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec

Steffen Klassert says:

====================
1) Fix a slab-out-of-bounds read in xfrm_address_filter.
From Lin Ma.

2) Fix the pfkey sadb_x_filter validation.
From Lin Ma.

3) Use the correct nla_policy structure for XFRMA_SEC_CTX.
From Lin Ma.

4) Fix warnings triggerable by bad packets in the encap functions.
From Herbert Xu.

5) Fix some slab-use-after-free in decode_session6.
From Zhengchao Shao.

6) Fix a possible NULL piointer dereference in xfrm_update_ae_params.
Lin Ma.

7) Add a forgotten nla_policy for XFRMA_MTIMER_THRESH.
From Lin Ma.

8) Don't leak offloaded policies.
From Leon Romanovsky.

9) Delete also the offloading part of an acquire state.
From Leon Romanovsky.

Please pull or let me know if there are problems.

show more ...

Merge drm/drm-next into drm-intel-next

Catching-up with drm-next and drm-intel-gt-next.
It will unblock a code refactor around the platform
definitions (names vs acronyms).

Signed-off-by: Rodrigo V

Merge drm/drm-next into drm-intel-next

Catching-up with drm-next and drm-intel-gt-next.
It will unblock a code refactor around the platform
definitions (names vs acronyms).

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

show more ...

Merge drm/drm-next into drm-intel-gt-next

Need to pull in b3e4aae612ec ("drm/i915/hdcp: Modify hdcp_gsc_message msg sending mechanism") as
a dependency for https://patchwork.freedesktop.org/series/1

Merge drm/drm-next into drm-intel-gt-next

Need to pull in b3e4aae612ec ("drm/i915/hdcp: Modify hdcp_gsc_message msg sending mechanism") as
a dependency for https://patchwork.freedesktop.org/series/121735/

Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

show more ...

xfrm: delete offloaded policy

The policy memory was released but not HW driver data. Add
call to xfrm_dev_policy_delete(), so drivers will have a chance
to release their resources.

Fixes: 919e43fad

xfrm: delete offloaded policy

The policy memory was released but not HW driver data. Add
call to xfrm_dev_policy_delete(), so drivers will have a chance
to release their resources.

Fixes: 919e43fad516 ("xfrm: add an interface to offload policy")
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>

show more ...

xfrm: add forgotten nla_policy for XFRMA_MTIMER_THRESH

The previous commit 4e484b3e969b ("xfrm: rate limit SA mapping change
message to user space") added one additional attribute named
XFRMA_MTIMER

xfrm: add forgotten nla_policy for XFRMA_MTIMER_THRESH

The previous commit 4e484b3e969b ("xfrm: rate limit SA mapping change
message to user space") added one additional attribute named
XFRMA_MTIMER_THRESH and described its type at compat_policy
(net/xfrm/xfrm_compat.c).

However, the author forgot to also describe the nla_policy at
xfrma_policy (net/xfrm/xfrm_user.c). Hence, this suppose NLA_U32 (4
bytes) value can be faked as empty (0 bytes) by a malicious user, which
leads to 4 bytes overflow read and heap information leak when parsing
nlattrs.

To exploit this, one malicious user can spray the SLUB objects and then
leverage this 4 bytes OOB read to leak the heap data into
x->mapping_maxage (see xfrm_update_ae_params(...)), and leak it to
userspace via copy_to_user_state_extra(...).

The above bug is assigned CVE-2023-3773. To fix it, this commit just
completes the nla_policy description for XFRMA_MTIMER_THRESH, which
enforces the length check and avoids such OOB read.

Fixes: 4e484b3e969b ("xfrm: rate limit SA mapping change message to user space")
Signed-off-by: Lin Ma <linma@zju.edu.cn>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>

show more ...

xfrm: add NULL check in xfrm_update_ae_params

Normally, x->replay_esn and x->preplay_esn should be allocated at
xfrm_alloc_replay_state_esn(...) in xfrm_state_construct(...), hence the
xfrm_update_a

xfrm: add NULL check in xfrm_update_ae_params

Normally, x->replay_esn and x->preplay_esn should be allocated at
xfrm_alloc_replay_state_esn(...) in xfrm_state_construct(...), hence the
xfrm_update_ae_params(...) is okay to update them. However, the current
implementation of xfrm_new_ae(...) allows a malicious user to directly
dereference a NULL pointer and crash the kernel like below.

BUG: kernel NULL pointer dereference, address: 0000000000000000
PGD 8253067 P4D 8253067 PUD 8e0e067 PMD 0
Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI
CPU: 0 PID: 98 Comm: poc.npd Not tainted 6.4.0-rc7-00072-gdad9774deaf1 #8
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.o4
RIP: 0010:memcpy_orig+0xad/0x140
Code: e8 4c 89 5f e0 48 8d 7f e0 73 d2 83 c2 20 48 29 d6 48 29 d7 83 fa 10 72 34 4c 8b 06 4c 8b 4e 08 c
RSP: 0018:ffff888008f57658 EFLAGS: 00000202
RAX: 0000000000000000 RBX: ffff888008bd0000 RCX: ffffffff8238e571
RDX: 0000000000000018 RSI: ffff888007f64844 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff888008f57818
R13: ffff888007f64aa4 R14: 0000000000000000 R15: 0000000000000000
FS: 00000000014013c0(0000) GS:ffff88806d600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000000054d8000 CR4: 00000000000006f0
Call Trace:
<TASK>
? __die+0x1f/0x70
? page_fault_oops+0x1e8/0x500
? __pfx_is_prefetch.constprop.0+0x10/0x10
? __pfx_page_fault_oops+0x10/0x10
? _raw_spin_unlock_irqrestore+0x11/0x40
? fixup_exception+0x36/0x460
? _raw_spin_unlock_irqrestore+0x11/0x40
? exc_page_fault+0x5e/0xc0
? asm_exc_page_fault+0x26/0x30
? xfrm_update_ae_params+0xd1/0x260
? memcpy_orig+0xad/0x140
? __pfx__raw_spin_lock_bh+0x10/0x10
xfrm_update_ae_params+0xe7/0x260
xfrm_new_ae+0x298/0x4e0
? __pfx_xfrm_new_ae+0x10/0x10
? __pfx_xfrm_new_ae+0x10/0x10
xfrm_user_rcv_msg+0x25a/0x410
? __pfx_xfrm_user_rcv_msg+0x10/0x10
? __alloc_skb+0xcf/0x210
? stack_trace_save+0x90/0xd0
? filter_irq_stacks+0x1c/0x70
? __stack_depot_save+0x39/0x4e0
? __kasan_slab_free+0x10a/0x190
? kmem_cache_free+0x9c/0x340
? netlink_recvmsg+0x23c/0x660
? sock_recvmsg+0xeb/0xf0
? __sys_recvfrom+0x13c/0x1f0
? __x64_sys_recvfrom+0x71/0x90
? do_syscall_64+0x3f/0x90
? entry_SYSCALL_64_after_hwframe+0x72/0xdc
? copyout+0x3e/0x50
netlink_rcv_skb+0xd6/0x210
? __pfx_xfrm_user_rcv_msg+0x10/0x10
? __pfx_netlink_rcv_skb+0x10/0x10
? __pfx_sock_has_perm+0x10/0x10
? mutex_lock+0x8d/0xe0
? __pfx_mutex_lock+0x10/0x10
xfrm_netlink_rcv+0x44/0x50
netlink_unicast+0x36f/0x4c0
? __pfx_netlink_unicast+0x10/0x10
? netlink_recvmsg+0x500/0x660
netlink_sendmsg+0x3b7/0x700

This Null-ptr-deref bug is assigned CVE-2023-3772. And this commit
adds additional NULL check in xfrm_update_ae_params to fix the NPD.

Fixes: d8647b79c3b7 ("xfrm: Add user interface for esn and big anti-replay windows")
Signed-off-by: Lin Ma <linma@zju.edu.cn>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>

show more ...

Merge tag 'v6.4' into next

Sync up with mainline to bring in updates to shared infrastructure.

net: xfrm: Amend XFRMA_SEC_CTX nla_policy structure

According to all consumers code of attrs[XFRMA_SEC_CTX], like

* verify_sec_ctx_len(), convert to xfrm_user_sec_ctx*
* xfrm_state_construct(), cal

net: xfrm: Amend XFRMA_SEC_CTX nla_policy structure

According to all consumers code of attrs[XFRMA_SEC_CTX], like

* verify_sec_ctx_len(), convert to xfrm_user_sec_ctx*
* xfrm_state_construct(), call security_xfrm_state_alloc whose prototype
is int security_xfrm_state_alloc(.., struct xfrm_user_sec_ctx *sec_ctx);
* copy_from_user_sec_ctx(), convert to xfrm_user_sec_ctx *
...

It seems that the expected parsing result for XFRMA_SEC_CTX should be
structure xfrm_user_sec_ctx, and the current xfrm_sec_ctx is confusing
and misleading (Luckily, they happen to have same size 8 bytes).

This commit amend the policy structure to xfrm_user_sec_ctx to avoid
ambiguity.

Fixes: cf5cb79f6946 ("[XFRM] netlink: Establish an attribute policy")
Signed-off-by: Lin Ma <linma@zju.edu.cn>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>

show more ...

net: xfrm: Fix xfrm_address_filter OOB read

We found below OOB crash:

[ 44.211730] ==================================================================
[ 44.212045] BUG: KASAN: slab-out-of-bounds

net: xfrm: Fix xfrm_address_filter OOB read

We found below OOB crash:

[ 44.211730] ==================================================================
[ 44.212045] BUG: KASAN: slab-out-of-bounds in memcmp+0x8b/0xb0
[ 44.212045] Read of size 8 at addr ffff88800870f320 by task poc.xfrm/97
[ 44.212045]
[ 44.212045] CPU: 0 PID: 97 Comm: poc.xfrm Not tainted 6.4.0-rc7-00072-gdad9774deaf1-dirty #4
[ 44.212045] Call Trace:
[ 44.212045] <TASK>
[ 44.212045] dump_stack_lvl+0x37/0x50
[ 44.212045] print_report+0xcc/0x620
[ 44.212045] ? __virt_addr_valid+0xf3/0x170
[ 44.212045] ? memcmp+0x8b/0xb0
[ 44.212045] kasan_report+0xb2/0xe0
[ 44.212045] ? memcmp+0x8b/0xb0
[ 44.212045] kasan_check_range+0x39/0x1c0
[ 44.212045] memcmp+0x8b/0xb0
[ 44.212045] xfrm_state_walk+0x21c/0x420
[ 44.212045] ? __pfx_dump_one_state+0x10/0x10
[ 44.212045] xfrm_dump_sa+0x1e2/0x290
[ 44.212045] ? __pfx_xfrm_dump_sa+0x10/0x10
[ 44.212045] ? __kernel_text_address+0xd/0x40
[ 44.212045] ? kasan_unpoison+0x27/0x60
[ 44.212045] ? mutex_lock+0x60/0xe0
[ 44.212045] ? __pfx_mutex_lock+0x10/0x10
[ 44.212045] ? kasan_save_stack+0x22/0x50
[ 44.212045] netlink_dump+0x322/0x6c0
[ 44.212045] ? __pfx_netlink_dump+0x10/0x10
[ 44.212045] ? mutex_unlock+0x7f/0xd0
[ 44.212045] ? __pfx_mutex_unlock+0x10/0x10
[ 44.212045] __netlink_dump_start+0x353/0x430
[ 44.212045] xfrm_user_rcv_msg+0x3a4/0x410
[ 44.212045] ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 44.212045] ? __pfx_xfrm_user_rcv_msg+0x10/0x10
[ 44.212045] ? __pfx_xfrm_dump_sa+0x10/0x10
[ 44.212045] ? __pfx_xfrm_dump_sa_done+0x10/0x10
[ 44.212045] ? __stack_depot_save+0x382/0x4e0
[ 44.212045] ? filter_irq_stacks+0x1c/0x70
[ 44.212045] ? kasan_save_stack+0x32/0x50
[ 44.212045] ? kasan_save_stack+0x22/0x50
[ 44.212045] ? kasan_set_track+0x25/0x30
[ 44.212045] ? __kasan_slab_alloc+0x59/0x70
[ 44.212045] ? kmem_cache_alloc_node+0xf7/0x260
[ 44.212045] ? kmalloc_reserve+0xab/0x120
[ 44.212045] ? __alloc_skb+0xcf/0x210
[ 44.212045] ? netlink_sendmsg+0x509/0x700
[ 44.212045] ? sock_sendmsg+0xde/0xe0
[ 44.212045] ? __sys_sendto+0x18d/0x230
[ 44.212045] ? __x64_sys_sendto+0x71/0x90
[ 44.212045] ? do_syscall_64+0x3f/0x90
[ 44.212045] ? entry_SYSCALL_64_after_hwframe+0x72/0xdc
[ 44.212045] ? netlink_sendmsg+0x509/0x700
[ 44.212045] ? sock_sendmsg+0xde/0xe0
[ 44.212045] ? __sys_sendto+0x18d/0x230
[ 44.212045] ? __x64_sys_sendto+0x71/0x90
[ 44.212045] ? do_syscall_64+0x3f/0x90
[ 44.212045] ? entry_SYSCALL_64_after_hwframe+0x72/0xdc
[ 44.212045] ? kasan_save_stack+0x22/0x50
[ 44.212045] ? kasan_set_track+0x25/0x30
[ 44.212045] ? kasan_save_free_info+0x2e/0x50
[ 44.212045] ? __kasan_slab_free+0x10a/0x190
[ 44.212045] ? kmem_cache_free+0x9c/0x340
[ 44.212045] ? netlink_recvmsg+0x23c/0x660
[ 44.212045] ? sock_recvmsg+0xeb/0xf0
[ 44.212045] ? __sys_recvfrom+0x13c/0x1f0
[ 44.212045] ? __x64_sys_recvfrom+0x71/0x90
[ 44.212045] ? do_syscall_64+0x3f/0x90
[ 44.212045] ? entry_SYSCALL_64_after_hwframe+0x72/0xdc
[ 44.212045] ? copyout+0x3e/0x50
[ 44.212045] netlink_rcv_skb+0xd6/0x210
[ 44.212045] ? __pfx_xfrm_user_rcv_msg+0x10/0x10
[ 44.212045] ? __pfx_netlink_rcv_skb+0x10/0x10
[ 44.212045] ? __pfx_sock_has_perm+0x10/0x10
[ 44.212045] ? mutex_lock+0x8d/0xe0
[ 44.212045] ? __pfx_mutex_lock+0x10/0x10
[ 44.212045] xfrm_netlink_rcv+0x44/0x50
[ 44.212045] netlink_unicast+0x36f/0x4c0
[ 44.212045] ? __pfx_netlink_unicast+0x10/0x10
[ 44.212045] ? netlink_recvmsg+0x500/0x660
[ 44.212045] netlink_sendmsg+0x3b7/0x700
[ 44.212045] ? __pfx_netlink_sendmsg+0x10/0x10
[ 44.212045] ? __pfx_netlink_sendmsg+0x10/0x10
[ 44.212045] sock_sendmsg+0xde/0xe0
[ 44.212045] __sys_sendto+0x18d/0x230
[ 44.212045] ? __pfx___sys_sendto+0x10/0x10
[ 44.212045] ? rcu_core+0x44a/0xe10
[ 44.212045] ? __rseq_handle_notify_resume+0x45b/0x740
[ 44.212045] ? _raw_spin_lock_irq+0x81/0xe0
[ 44.212045] ? __pfx___rseq_handle_notify_resume+0x10/0x10
[ 44.212045] ? __pfx_restore_fpregs_from_fpstate+0x10/0x10
[ 44.212045] ? __pfx_blkcg_maybe_throttle_current+0x10/0x10
[ 44.212045] ? __pfx_task_work_run+0x10/0x10
[ 44.212045] __x64_sys_sendto+0x71/0x90
[ 44.212045] do_syscall_64+0x3f/0x90
[ 44.212045] entry_SYSCALL_64_after_hwframe+0x72/0xdc
[ 44.212045] RIP: 0033:0x44b7da
[ 44.212045] RSP: 002b:00007ffdc8838548 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
[ 44.212045] RAX: ffffffffffffffda RBX: 00007ffdc8839978 RCX: 000000000044b7da
[ 44.212045] RDX: 0000000000000038 RSI: 00007ffdc8838770 RDI: 0000000000000003
[ 44.212045] RBP: 00007ffdc88385b0 R08: 00007ffdc883858c R09: 000000000000000c
[ 44.212045] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
[ 44.212045] R13: 00007ffdc8839968 R14: 00000000004c37d0 R15: 0000000000000001
[ 44.212045] </TASK>
[ 44.212045]
[ 44.212045] Allocated by task 97:
[ 44.212045] kasan_save_stack+0x22/0x50
[ 44.212045] kasan_set_track+0x25/0x30
[ 44.212045] __kasan_kmalloc+0x7f/0x90
[ 44.212045] __kmalloc_node_track_caller+0x5b/0x140
[ 44.212045] kmemdup+0x21/0x50
[ 44.212045] xfrm_dump_sa+0x17d/0x290
[ 44.212045] netlink_dump+0x322/0x6c0
[ 44.212045] __netlink_dump_start+0x353/0x430
[ 44.212045] xfrm_user_rcv_msg+0x3a4/0x410
[ 44.212045] netlink_rcv_skb+0xd6/0x210
[ 44.212045] xfrm_netlink_rcv+0x44/0x50
[ 44.212045] netlink_unicast+0x36f/0x4c0
[ 44.212045] netlink_sendmsg+0x3b7/0x700
[ 44.212045] sock_sendmsg+0xde/0xe0
[ 44.212045] __sys_sendto+0x18d/0x230
[ 44.212045] __x64_sys_sendto+0x71/0x90
[ 44.212045] do_syscall_64+0x3f/0x90
[ 44.212045] entry_SYSCALL_64_after_hwframe+0x72/0xdc
[ 44.212045]
[ 44.212045] The buggy address belongs to the object at ffff88800870f300
[ 44.212045] which belongs to the cache kmalloc-64 of size 64
[ 44.212045] The buggy address is located 32 bytes inside of
[ 44.212045] allocated 36-byte region [ffff88800870f300, ffff88800870f324)
[ 44.212045]
[ 44.212045] The buggy address belongs to the physical page:
[ 44.212045] page:00000000e4de16ee refcount:1 mapcount:0 mapping:000000000 ...
[ 44.212045] flags: 0x100000000000200(slab|node=0|zone=1)
[ 44.212045] page_type: 0xffffffff()
[ 44.212045] raw: 0100000000000200 ffff888004c41640 dead000000000122 0000000000000000
[ 44.212045] raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000
[ 44.212045] page dumped because: kasan: bad access detected
[ 44.212045]
[ 44.212045] Memory state around the buggy address:
[ 44.212045] ffff88800870f200: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[ 44.212045] ffff88800870f280: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc
[ 44.212045] >ffff88800870f300: 00 00 00 00 04 fc fc fc fc fc fc fc fc fc fc fc
[ 44.212045] ^
[ 44.212045] ffff88800870f380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 44.212045] ffff88800870f400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 44.212045] ==================================================================

By investigating the code, we find the root cause of this OOB is the lack
of checks in xfrm_dump_sa(). The buggy code allows a malicious user to pass
arbitrary value of filter->splen/dplen. Hence, with crafted xfrm states,
the attacker can achieve 8 bytes heap OOB read, which causes info leak.

if (attrs[XFRMA_ADDRESS_FILTER]) {
filter = kmemdup(nla_data(attrs[XFRMA_ADDRESS_FILTER]),
sizeof(*filter), GFP_KERNEL);
if (filter == NULL)
return -ENOMEM;
// NO MORE CHECKS HERE !!!
}

This patch fixes the OOB by adding necessary boundary checks, just like
the code in pfkey_dump() function.

Fixes: d3623099d350 ("ipsec: add support of limited SA dump")
Signed-off-by: Lin Ma <linma@zju.edu.cn>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>

show more ...

Merge branch 'for-6.5/apple' into for-linus

- improved support for Keychron K8 keyboard (Lasse Brun)

Merge tag 'v6.4' into rdma.git for-next

Linux 6.4

Resolve conflicts between rdma rc and next in rxe_cq matching linux-next:

drivers/infiniband/sw/rxe/rxe_cq.c:
https://lore.kernel.org/r/20230622

Merge tag 'v6.4' into rdma.git for-next

Linux 6.4

Resolve conflicts between rdma rc and next in rxe_cq matching linux-next:

drivers/infiniband/sw/rxe/rxe_cq.c:
https://lore.kernel.org/r/20230622115246.365d30ad@canb.auug.org.au

Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>

show more ...

Merge tag 'asoc-v6.5' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

ASoC: Updates for v6.5

A fairly quiet release from a core and framework point of view, but a
ve

Merge tag 'asoc-v6.5' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

ASoC: Updates for v6.5

A fairly quiet release from a core and framework point of view, but a
very big one from the point of view of new drivers:

- More refectoring from Morimoto-san, this time mainly around DAI
links and how we control the ordering of trigger() callbacks.
- Convert a lot of drivers to use maple tree based caches.
- Lots of work on the x86 driver stack.
- Compressed audio support for Qualcomm.
- Support for AMD SoundWire, Analog Devices SSM3515, Google Chameleon,
Ingenic X1000, Intel systems with various CODECs, Longsoon platforms,
Maxim MAX98388, Mediatek MT8188, Nuvoton NAU8825C, NXP platforms with
NAU8822, Qualcomm WSA884x, StarFive JH7110, Texas Instruments TAS2781.

show more ...