| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CANn89iK=vK4FCgXP_NMTdAw+QAGNMbpqNubjY5e+XvtNshELUw@mail.gmail.com>
Date: Wed, 17 Dec 2025 19:24:07 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: bestswngs@...il.com
Cc: security@...nel.org, davem@...emloft.net, kuba@...nel.org,
pabeni@...hat.com, horms@...nel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, xmei5@....edu,
Willem de Bruijn <willemb@...gle.com>
Subject: Re: [PATCH net v4] net: skbuff: add usercopy region to skbuff_fclone_cache
On Tue, Dec 16, 2025 at 9:51 AM <bestswngs@...il.com> wrote:
>
> From: Weiming Shi <bestswngs@...il.com>
>
> skbuff_fclone_cache was created without defining a usercopy region, [1]
> unlike skbuff_head_cache which properly whitelists the cb[] field. [2]
> This causes a usercopy BUG() when CONFIG_HARDENED_USERCOPY is enabled
> and the kernel attempts to copy sk_buff.cb data to userspace via
> sock_recv_errqueue() -> put_cmsg().
>
> The crash occurs when:
> 1. TCP allocates an skb using alloc_skb_fclone()
> (from skbuff_fclone_cache) [1]
> 2. The skb is cloned via skb_clone() using the pre-allocated fclone [3]
> 3. The cloned skb is queued to sk_error_queue for timestamp reporting
> 4. Userspace reads the error queue via recvmsg(MSG_ERRQUEUE)
> 5. sock_recv_errqueue() calls put_cmsg() to copy serr->ee from skb->cb [4]
> 6. __check_heap_object() fails because skbuff_fclone_cache has no
> usercopy whitelist [5]
>
> When cloned skbs allocated from skbuff_fclone_cache are used in the
> socket error queue, accessing the sock_exterr_skb structure in skb->cb
> via put_cmsg() triggers a usercopy hardening violation:
>
> [ 5.379589] usercopy: Kernel memory exposure attempt detected from SLUB object 'skbuff_fclone_cache' (offset 296, size 16)!
> [ 5.382796] kernel BUG at mm/usercopy.c:102!
> [ 5.383923] Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
> [ 5.384903] CPU: 1 UID: 0 PID: 138 Comm: poc_put_cmsg Not tainted 6.12.57 #7
> [ 5.384903] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
> [ 5.384903] RIP: 0010:usercopy_abort+0x6c/0x80
> [ 5.384903] Code: 1a 86 51 48 c7 c2 40 15 1a 86 41 52 48 c7 c7 c0 15 1a 86 48 0f 45 d6 48 c7 c6 80 15 1a 86 48 89 c1 49 0f 45 f3 e8 84 27 88 ff <0f> 0b 490
> [ 5.384903] RSP: 0018:ffffc900006f77a8 EFLAGS: 00010246
> [ 5.384903] RAX: 000000000000006f RBX: ffff88800f0ad2a8 RCX: 1ffffffff0f72e74
> [ 5.384903] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff87b973a0
> [ 5.384903] RBP: 0000000000000010 R08: 0000000000000000 R09: fffffbfff0f72e74
> [ 5.384903] R10: 0000000000000003 R11: 79706f6372657375 R12: 0000000000000001
> [ 5.384903] R13: ffff88800f0ad2b8 R14: ffffea00003c2b40 R15: ffffea00003c2b00
> [ 5.384903] FS: 0000000011bc4380(0000) GS:ffff8880bf100000(0000) knlGS:0000000000000000
> [ 5.384903] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 5.384903] CR2: 000056aa3b8e5fe4 CR3: 000000000ea26004 CR4: 0000000000770ef0
> [ 5.384903] PKRU: 55555554
> [ 5.384903] Call Trace:
> [ 5.384903] <TASK>
> [ 5.384903] __check_heap_object+0x9a/0xd0
> [ 5.384903] __check_object_size+0x46c/0x690
> [ 5.384903] put_cmsg+0x129/0x5e0
> [ 5.384903] sock_recv_errqueue+0x22f/0x380
> [ 5.384903] tls_sw_recvmsg+0x7ed/0x1960
> [ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5
> [ 5.384903] ? schedule+0x6d/0x270
> [ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5
> [ 5.384903] ? mutex_unlock+0x81/0xd0
> [ 5.384903] ? __pfx_mutex_unlock+0x10/0x10
> [ 5.384903] ? __pfx_tls_sw_recvmsg+0x10/0x10
> [ 5.384903] ? _raw_spin_lock_irqsave+0x8f/0xf0
> [ 5.384903] ? _raw_read_unlock_irqrestore+0x20/0x40
> [ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5
>
> The crash offset 296 corresponds to skb2->cb within skbuff_fclones:
> - sizeof(struct sk_buff) = 232
> - offsetof(struct sk_buff, cb) = 40
> - offset of skb2.cb in fclones = 232 + 40 = 272
> - crash offset 296 = 272 + 24 (inside sock_exterr_skb.ee)
>
> Fix this by using kmem_cache_create_usercopy() for skbuff_fclone_cache
> and whitelisting the cb regions.
> In our patch, we referenced
> net: Whitelist the `skb_head_cache` "cb" field. [6]
>
> Fix by using kmem_cache_create_usercopy() with the same cb[] region
> whitelist as skbuff_head_cache.
>
> [1] https://elixir.bootlin.com/linux/v6.12.62/source/net/ipv4/tcp.c#L885
> [2] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5104
> [3] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5566
> [4] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5491
> [5] https://elixir.bootlin.com/linux/v6.12.62/source/mm/slub.c#L5719
> [6] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=79a8a642bf05c
>
> Fixes: 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0")
> Reported-by: Xiang Mei <xmei5@....edu>
> Signed-off-by: Weiming Shi <bestswngs@...il.com>
> ---
> v2: Fix the Commit Message
> v3: Add "From" email address, Fix "CC" and "TO" email address
> v4: Fix The Patch Code
>
> net/core/skbuff.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index a00808f7be6a..89c98ce6106a 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -5157,10 +5157,12 @@ void __init skb_init(void)
> NULL);
> skbuff_cache_size = kmem_cache_size(net_hotdata.skbuff_cache);
>
> - net_hotdata.skbuff_fclone_cache = kmem_cache_create("skbuff_fclone_cache",
> + net_hotdata.skbuff_fclone_cache = kmem_cache_create_usercopy("skbuff_fclone_cache",
> sizeof(struct sk_buff_fclones),
> 0,
> SLAB_HWCACHE_ALIGN|SLAB_PANIC,
> + offsetof(struct sk_buff, cb),
> + sizeof(struct sk_buff) + sizeof_field(struct sk_buff, cb),
> NULL);
I have a bad feeling about this patch.
Really we should not put a fast clone skb back in error queue in the
first place, because we can not control how long the (possibly large)
skb will stay there.
Things like skb_fclone_busy() would need a fix otherwise.
Powered by blists - more mailing lists