~canonical-kernel/ubuntu/+source/linux-oem/+git/jammy:oem-6.0-next
- Get this branch:
-
git clone
-b oem-6.0-next
https://git.launchpad.net/~canonical-kernel/ubuntu/+source/linux-oem/+git/jammy
Branch merges
Related source package recipes
Branch information
- Name:
- oem-6.0-next
Recent commits
- 0171567... by Timo Aaltonen
-
UBUNTU: Ubuntu-
oem-6.0- 6.0.0-1021. 21 Signed-off-by: Timo Aaltonen <email address hidden>
- 7b04605... by Timo Aaltonen
-
UBUNTU: [Config] Update gcc version
Signed-off-by: Timo Aaltonen <email address hidden>
- b151433... by Timo Aaltonen
-
UBUNTU: [Packaging] resync update-
dkms-versions helper BugLink: https:/
/bugs.launchpad .net/bugs/ 1786013
Signed-off-by: Timo Aaltonen <email address hidden> - b59afa7... by Timo Aaltonen
-
UBUNTU: link-to-tracker: update tracking bug
BugLink: https:/
/bugs.launchpad .net/bugs/ 2034204
Properties: no-test-build
Signed-off-by: Timo Aaltonen <email address hidden> - bc32fdb... by Timo Aaltonen
-
UBUNTU: Start new release
Ignore: yes
Signed-off-by: Timo Aaltonen <email address hidden> - 89a0689... by "t.feng" <email address hidden>
-
ipvlan:Fix out-of-bounds caused by unclear skb->cb
If skb enqueue the qdisc, fq_skb_
cb(skb) ->time_ to_send is changed which
is actually skb->cb, and IPCB(skb_in)->opt will be used in
__ip_options_echo. It is possible that memcpy is out of bounds and lead
to stack overflow.
We should clear skb->cb before ip_local_out or ip6_local_out.v2:
1. clean the stack info
2. use IPCB/IP6CB instead of skb->cbcrash on stable-
5.10(reproduce in kasan kernel).
Stack info:
[ 2203.651571] BUG: KASAN: stack-out-of-bounds in
__ip_options_echo+0x589/ 0x800
[ 2203.653327] Write of size 4 at addr ffff88811a388f27 by task
swapper/3/0
[ 2203.655460] CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Not tainted
5.10.0-60.18.0. 50.h856. kasan.eulerosv2 r11.x86_ 64 #1
[ 2203.655466] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.10.2-0-g5f4c7b1- 20181220_ 000000- szxrtosci10000 04/01/2014
[ 2203.655475] Call Trace:
[ 2203.655481] <IRQ>
[ 2203.655501] dump_stack+0x9c/0xd3
[ 2203.655514] print_address_description. constprop. 0+0x19/ 0x170
[ 2203.655530] __kasan_report. cold+0x6c/ 0x84
[ 2203.655586] kasan_report+0x3a/0x50
[ 2203.655594] check_memory_region+ 0xfd/0x1f0
[ 2203.655601] memcpy+0x39/0x60
[ 2203.655608] __ip_options_echo+0x589/ 0x800
[ 2203.655654] __icmp_send+0x59a/ 0x960
[ 2203.655755] nf_send_unreach+ 0x129/0x3d0 [nf_reject_ipv4]
[ 2203.655763] reject_tg+0x77/ 0x1bf [ipt_REJECT]
[ 2203.655772] ipt_do_table+0x691/ 0xa40 [ip_tables]
[ 2203.655821] nf_hook_slow+0x69/ 0x100
[ 2203.655828] __ip_local_out+0x21e/ 0x2b0
[ 2203.655857] ip_local_out+0x28/ 0x90
[ 2203.655868] ipvlan_process_ v4_outbound+ 0x21e/0x260 [ipvlan]
[ 2203.655931] ipvlan_xmit_mode_ l3+0x3bd/ 0x400 [ipvlan]
[ 2203.655967] ipvlan_queue_xmit+ 0xb3/0x190 [ipvlan]
[ 2203.655977] ipvlan_start_xmit+ 0x2e/0xb0 [ipvlan]
[ 2203.655984] xmit_one.constprop. 0+0xe1/ 0x280
[ 2203.655992] dev_hard_start_xmit+ 0x62/0x100
[ 2203.656000] sch_direct_xmit+0x215/ 0x640
[ 2203.656028] __qdisc_run+0x153/ 0x1f0
[ 2203.656069] __dev_queue_xmit+0x77f/ 0x1030
[ 2203.656173] ip_finish_output2+ 0x59b/0xc20
[ 2203.656244] __ip_finish_output. part.0+ 0x318/0x3d0
[ 2203.656312] ip_finish_output+ 0x168/0x190
[ 2203.656320] ip_output+0x12d/0x220
[ 2203.656357] __ip_queue_xmit+0x392/ 0x880
[ 2203.656380] __tcp_transmit_skb+0x1088/ 0x11c0
[ 2203.656436] __tcp_retransmit_skb+0x475/ 0xa30
[ 2203.656505] tcp_retransmit_skb+0x2d/ 0x190
[ 2203.656512] tcp_retransmit_timer+0x3af/ 0x9a0
[ 2203.656519] tcp_write_timer_handler+ 0x3ba/0x510
[ 2203.656529] tcp_write_timer+0x55/ 0x180
[ 2203.656542] call_timer_fn+0x3f/ 0x1d0
[ 2203.656555] expire_timers+ 0x160/0x200
[ 2203.656562] run_timer_softirq+ 0x1f4/0x480
[ 2203.656606] __do_softirq+0xfd/0x402
[ 2203.656613] asm_call_irq_on_ stack+0x12/ 0x20
[ 2203.656617] </IRQ>
[ 2203.656623] do_softirq_own_stack+ 0x37/0x50
[ 2203.656631] irq_exit_rcu+0x134/ 0x1a0
[ 2203.656639] sysvec_apic_timer_ interrupt+ 0x36/0x80
[ 2203.656646] asm_sysvec_apic_timer_ interrupt+ 0x12/0x20
[ 2203.656654] RIP: 0010:default_idle+0x13/ 0x20
[ 2203.656663] Code: 89 f0 5d 41 5c 41 5d 41 5e c3 cc cc cc cc cc cc cc
cc cc cc cc cc cc 0f 1f 44 00 00 0f 1f 44 00 00 0f 00 2d 9f 32 57 00 fb
f4 <c3> cc cc cc cc 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 54 be 08
[ 2203.656668] RSP: 0018:ffff88810036fe78 EFLAGS: 00000256
[ 2203.656676] RAX: ffffffffaf2a87f0 RBX: ffff888100360000 RCX:
ffffffffaf290191
[ 2203.656681] RDX: 0000000000098b5e RSI: 0000000000000004 RDI:
ffff88811a3c4f60
[ 2203.656686] RBP: 0000000000000000 R08: 0000000000000001 R09:
ffff88811a3c4f63
[ 2203.656690] R10: ffffed10234789ec R11: 0000000000000001 R12:
0000000000000003
[ 2203.656695] R13: ffff888100360000 R14: 0000000000000000 R15:
0000000000000000
[ 2203.656729] default_idle_call+ 0x5a/0x150
[ 2203.656735] cpuidle_idle_call+ 0x1c6/0x220
[ 2203.656780] do_idle+0xab/0x100
[ 2203.656786] cpu_startup_entry+0x19/ 0x20
[ 2203.656793] secondary_startup_ 64_no_verify+ 0xc2/0xcb [ 2203.657409] The buggy address belongs to the page:
[ 2203.658648] page:0000000027a9842f refcount:1 mapcount:0
mapping:000000000000000 0 index:0x0 pfn:0x11a388
[ 2203.658665] flags:
0x17ffffc0001000(reserved| node=0| zone=2| lastcpupid= 0x1fffff)
[ 2203.658675] raw: 0017ffffc0001000 ffffea000468e208 ffffea000468e208
0000000000000000
[ 2203.658682] raw: 0000000000000000 0000000000000000 00000001ffffffff
0000000000000000
[ 2203.658686] page dumped because: kasan: bad access detectedTo reproduce(ipvlan with IPVLAN_MODE_L3):
Env setting:
============== ======= ======= ======= ======= ======= ======
modprobe ipvlan ipvlan_default_ mode=1
sysctl net.ipv4.conf.eth0. forwarding= 1
iptables -t nat -A POSTROUTING -s 20.0.0.0/255.255. 255.0 -o eth0 -j
MASQUERADE
ip link add gw link eth0 type ipvlan
ip -4 addr add 20.0.0.254/24 dev gw
ip netns add net1
ip link add ipv1 link eth0 type ipvlan
ip link set ipv1 netns net1
ip netns exec net1 ip link set ipv1 up
ip netns exec net1 ip -4 addr add 20.0.0.4/24 dev ipv1
ip netns exec net1 route add default gw 20.0.0.254
ip netns exec net1 tc qdisc add dev ipv1 root netem loss 10%
ifconfig gw up
iptables -t filter -A OUTPUT -p tcp --dport 8888 -j REJECT --reject-with
icmp-port-unreachable
============== ======= ======= ======= ======= ======= ======
And then excute the shell(curl any address of eth0 can reach):for((i=
1;i<=100000; i++))
do
ip netns exec net1 curl x.x.x.x:8888
done
============== ======= ======= ======= ======= ======= ====== Fixes: 2ad7bf363841 ("ipvlan: Initial check-in of the IPVLAN driver.")
Signed-off-by: "t.feng" <email address hidden>
Suggested-by: Florian Westphal <email address hidden>
Reviewed-by: Paolo Abeni <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit 90cbed5247439a966b645b34eb0a2e 037836ea8e)
CVE-2023-3090
Signed-off-by: Yuxuan Luo <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden> - 8a5c7da... by Filipe Manana <email address hidden>
-
btrfs: fix race between quota disable and quota assign ioctls
The quota assign ioctl can currently run in parallel with a quota disable
ioctl call. The assign ioctl uses the quota root, while the disable ioctl
frees that root, and therefore we can have a use-after-free triggered in
the assign ioctl, leading to a trace like the following when KASAN is
enabled:[672.723][T736] BUG: KASAN: slab-use-after-free in btrfs_search_
slot+0x2962/ 0x2db0
[672.723][T736] Read of size 8 at addr ffff888022ec0208 by task btrfs_search_sl/27736
[672.724][T736]
[672.725][T736] CPU: 1 PID: 27736 Comm: btrfs_search_sl Not tainted 6.3.0-rc3 #37
[672.723][T736] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[672.727][T736] Call Trace:
[672.728][T736] <TASK>
[672.728][T736] dump_stack_lvl+0xd9/ 0x150
[672.725][T736] print_report+0xc1/0x5e0
[672.720][T736] ? __virt_addr_valid+ 0x61/0x2e0
[672.727][T736] ? __phys_addr+0xc9/ 0x150
[672.725][T736] ? btrfs_search_slot+0x2962/ 0x2db0
[672.722][T736] kasan_report+0xc0/0xf0
[672.729][T736] ? btrfs_search_slot+0x2962/ 0x2db0
[672.724][T736] btrfs_search_slot+0x2962/ 0x2db0
[672.723][T736] ? fs_reclaim_acquire+ 0xba/0x160
[672.722][T736] ? split_leaf+0x13d0/ 0x13d0
[672.726][T736] ? rcu_is_watching+ 0x12/0xb0
[672.723][T736] ? kmem_cache_alloc+0x338/ 0x3c0
[672.722][T736] update_qgroup_ status_ item+0xf7/ 0x320
[672.724][T736] ? add_qgroup_rb+0x3d0/ 0x3d0
[672.739][T736] ? do_raw_spin_lock+ 0x12d/0x2b0
[672.730][T736] ? spin_bug+0x1d0/0x1d0
[672.737][T736] btrfs_run_qgroups+ 0x5de/0x840
[672.730][T736] ? btrfs_qgroup_rescan_ worker+ 0xa70/0xa70
[672.738][T736] ? __del_qgroup_relation+ 0x4ba/0xe00
[672.738][T736] btrfs_ioctl+0x3d58/ 0x5d80
[672.735][T736] ? tomoyo_path_number_ perm+0x16a/ 0x550
[672.737][T736] ? tomoyo_execute_ permission+ 0x4a0/0x4a0
[672.731][T736] ? btrfs_ioctl_get_supported_ features+ 0x50/0x50
[672.737][T736] ? __sanitizer_cov_trace_ switch+ 0x54/0x90
[672.734][T736] ? do_vfs_ioctl+0x132/ 0x1660
[672.730][T736] ? vfs_fileattr_set+0xc40/ 0xc40
[672.730][T736] ? _raw_spin_unlock_ irq+0x2e/ 0x50
[672.732][T736] ? sigprocmask+0xf2/0x340
[672.737][T736] ? __fget_files+0x26a/ 0x480
[672.732][T736] ? bpf_lsm_file_ioctl+ 0x9/0x10
[672.738][T736] ? btrfs_ioctl_get_supported_ features+ 0x50/0x50
[672.736][T736] __x64_sys_ioctl+0x198/ 0x210
[672.736][T736] do_syscall_64+0x39/ 0xb0
[672.731][T736] entry_SYSCALL_64_after_ hwframe+ 0x63/0xcd
[672.739][T736] RIP: 0033:0x4556ad
[672.742][T736] </TASK>
[672.743][T736]
[672.748][T736] Allocated by task 27677:
[672.743][T736] kasan_save_stack+0x22/ 0x40
[672.741][T736] kasan_set_track+0x25/ 0x30
[672.741][T736] __kasan_kmalloc+ 0xa4/0xb0
[672.749][T736] btrfs_alloc_root+0x48/ 0x90
[672.746][T736] btrfs_create_tree+0x146/ 0xa20
[672.744][T736] btrfs_quota_enable+ 0x461/0x1d20
[672.743][T736] btrfs_ioctl+0x4a1c/ 0x5d80
[672.747][T736] __x64_sys_ioctl+0x198/ 0x210
[672.749][T736] do_syscall_64+0x39/ 0xb0
[672.744][T736] entry_SYSCALL_64_after_ hwframe+ 0x63/0xcd
[672.756][T736]
[672.757][T736] Freed by task 27677:
[672.759][T736] kasan_save_stack+0x22/ 0x40
[672.759][T736] kasan_set_track+0x25/ 0x30
[672.756][T736] kasan_save_free_info+ 0x2e/0x50
[672.751][T736] ____kasan_slab_free+ 0x162/0x1c0
[672.758][T736] slab_free_freelist_ hook+0x89/ 0x1c0
[672.752][T736] __kmem_cache_free+ 0xaf/0x2e0
[672.752][T736] btrfs_put_root+0x1ff/ 0x2b0
[672.759][T736] btrfs_quota_disable+ 0x80a/0xbc0
[672.752][T736] btrfs_ioctl+0x3e5f/ 0x5d80
[672.756][T736] __x64_sys_ioctl+0x198/ 0x210
[672.753][T736] do_syscall_64+0x39/ 0xb0
[672.765][T736] entry_SYSCALL_64_after_ hwframe+ 0x63/0xcd
[672.769][T736]
[672.768][T736] The buggy address belongs to the object at ffff888022ec0000
[672.768][T736] which belongs to the cache kmalloc-4k of size 4096
[672.769][T736] The buggy address is located 520 bytes inside of
[672.769][T736] freed 4096-byte region [ffff888022ec0000, ffff888022ec1000)
[672.760][T736]
[672.764][T736] The buggy address belongs to the physical page:
[672.761][T736] page:ffffea00008bb000 refcount:1 mapcount:0 mapping: 000000000000000 0 index:0x0 pfn:0x22ec0
[672.766][T736] head:ffffea00008bb000 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
[672.779][T736] flags: 0xfff00000010200(slab| head|node= 0|zone= 1|lastcpupid= 0x7ff)
[672.770][T736] raw: 00fff00000010200 ffff888012842140 ffffea000054ba00 dead000000000002
[672.770][T736] raw: 0000000000000000 0000000000040004 00000001ffffffff 0000000000000000
[672.771][T736] page dumped because: kasan: bad access detected
[672.778][T736] page_owner tracks the page as allocated
[672.777][T736] page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd2040(__GFP_IO| __GFP_NOWARN| __GFP_NORETRY| __GFP_COMP| __GFP_NOMEMALLO C), pid 88
[672.779][T736] get_page_from_freelist+ 0x119c/ 0x2d50
[672.779][T736] __alloc_pages+0x1cb/ 0x4a0
[672.776][T736] alloc_pages+0x1aa/0x270
[672.773][T736] allocate_slab+0x260/ 0x390
[672.771][T736] ___slab_alloc+0xa9a/ 0x13e0
[672.778][T736] __slab_alloc.constprop .0+0x56/ 0xb0
[672.771][T736] __kmem_cache_alloc_ node+0x136/ 0x320
[672.789][T736] __kmalloc+0x4e/0x1a0
[672.783][T736] tomoyo_realpath_ from_path+ 0xc3/0x600
[672.781][T736] tomoyo_path_perm+ 0x22f/0x420
[672.782][T736] tomoyo_path_unlink+ 0x92/0xd0
[672.780][T736] security_path_unlink+ 0xdb/0x150
[672.788][T736] do_unlinkat+0x377/0x680
[672.788][T736] __x64_sys_unlink+ 0xca/0x110
[672.789][T736] do_syscall_64+0x39/ 0xb0
[672.783][T736] entry_SYSCALL_64_after_ hwframe+ 0x63/0xcd
[672.784][T736] page last free stack trace:
[672.787][T736] free_pcp_prepare+ 0x4e5/0x920
[672.787][T736] free_unref_page+0x1d/ 0x4e0
[672.784][T736] __unfreeze_partials+ 0x17c/0x1a0
[672.797][T736] qlist_free_all+0x6a/ 0x180
[672.796][T736] kasan_quarantine_reduce+ 0x189/0x1d0
[672.797][T736] __kasan_slab_alloc+ 0x64/0x90
[672.793][T736] kmem_cache_alloc+0x17c/ 0x3c0
[672.799][T736] getname_flags.part. 0+0x50/ 0x4e0
[672.799][T736] getname_flags+0x9e/ 0xe0
[672.792][T736] vfs_fstatat+0x77/0xb0
[672.791][T736] __do_sys_newlstat+ 0x84/0x100
[672.798][T736] do_syscall_64+0x39/ 0xb0
[672.796][T736] entry_SYSCALL_64_after_ hwframe+ 0x63/0xcd
[672.790][T736]
[672.791][T736] Memory state around the buggy address:
[672.799][T736] ffff888022ec0100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[672.805][T736] ffff888022ec0180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[672.802][T736] >ffff888022ec0200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[672.809][T736] ^
[672.809][T736] ffff888022ec0280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[672.809][T736] ffff888022ec0300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fbFix this by having the qgroup assign ioctl take the qgroup ioctl mutex
before calling btrfs_run_qgroups( ), which is what all qgroup ioctls should
call.Reported-by: butt3rflyh4ck <email address hidden>
Link: https://lore.kernel. org<email address hidden>/
CC: <email address hidden> # 5.10+
Reviewed-by: Qu Wenruo <email address hidden>
Signed-off-by: Filipe Manana <email address hidden>
Reviewed-by: David Sterba <email address hidden>
Signed-off-by: David Sterba <email address hidden>
(cherry picked from commit 2f1a6be12ab6c8470d5776e6864472 6c94257c54)
CVE-2023-1611
Signed-off-by: Yuxuan Luo <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden> - 29f2bb4... by Laszlo Ersek (Red Hat)
-
net: tap_open(): set sk_uid from current_fsuid()
Commit 66b2c338adce initializes the "sk_uid" field in the protocol socket
(struct sock) from the "/dev/tapX" device node's owner UID. Per original
commit 86741ec25462 ("net: core: Add a UID field to struct sock.",
2016-11-04), that's wrong: the idea is to cache the UID of the userspace
process that creates the socket. Commit 86741ec25462 mentions socket() and
accept(); with "tap", the action that creates the socket is
open("/dev/tapX").Therefore the device node's owner UID is irrelevant. In most cases,
"/dev/tapX" will be owned by root, so in practice, commit 66b2c338adce has
no observable effect:- before, "sk_uid" would be zero, due to undefined behavior
(CVE-2023-1076),- after, "sk_uid" would be zero, due to "/dev/tapX" being owned by root.
What matters is the (fs)UID of the process performing the open(), so cache
that in "sk_uid".Cc: Eric Dumazet <email address hidden>
Cc: Lorenzo Colitti <email address hidden>
Cc: Paolo Abeni <email address hidden>
Cc: Pietro Borrello <email address hidden>
Cc: <email address hidden>
Cc: <email address hidden>
Fixes: 66b2c338adce ("tap: tap_open(): correctly initialize socket uid")
Bugzilla: https://bugzilla. redhat. com/show_ bug.cgi? id=2173435
Signed-off-by: Laszlo Ersek <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit 5c9241f3ceab3257abe2923a59950d b0dc8bb737)
CVE-2023-4194
Signed-off-by: Cengiz Can <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden> - 37c69c7... by Laszlo Ersek (Red Hat)
-
net: tun_chr_open(): set sk_uid from current_fsuid()
Commit a096ccca6e50 initializes the "sk_uid" field in the protocol socket
(struct sock) from the "/dev/net/tun" device node's owner UID. Per
original commit 86741ec25462 ("net: core: Add a UID field to struct
sock.", 2016-11-04), that's wrong: the idea is to cache the UID of the
userspace process that creates the socket. Commit 86741ec25462 mentions
socket() and accept(); with "tun", the action that creates the socket is
open("/dev/net/ tun"). Therefore the device node's owner UID is irrelevant. In most cases,
"/dev/net/tun" will be owned by root, so in practice, commit a096ccca6e50
has no observable effect:- before, "sk_uid" would be zero, due to undefined behavior
(CVE-2023-1076),- after, "sk_uid" would be zero, due to "/dev/net/tun" being owned by root.
What matters is the (fs)UID of the process performing the open(), so cache
that in "sk_uid".Cc: Eric Dumazet <email address hidden>
Cc: Lorenzo Colitti <email address hidden>
Cc: Paolo Abeni <email address hidden>
Cc: Pietro Borrello <email address hidden>
Cc: <email address hidden>
Cc: <email address hidden>
Fixes: a096ccca6e50 ("tun: tun_chr_open(): correctly initialize socket uid")
Bugzilla: https://bugzilla. redhat. com/show_ bug.cgi? id=2173435
Signed-off-by: Laszlo Ersek <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit 9bc3047374d5bec163e83e743709e2 3753376f0c)
CVE-2023-4194
Signed-off-by: Cengiz Can <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden> - 4f9bf58... by Pietro Borrello <email address hidden>
-
tap: tap_open(): correctly initialize socket uid
sock_init_data() assumes that the `struct socket` passed in input is
contained in a `struct socket_alloc` allocated with sock_alloc().
However, tap_open() passes a `struct socket` embedded in a `struct
tap_queue` allocated with sk_alloc().
This causes a type confusion when issuing a container_of() with
SOCK_INODE() in sock_init_data() which results in assigning a wrong
sk_uid to the `struct sock` in input.
On default configuration, the type confused field overlaps with
padding bytes between `int vnet_hdr_sz` and `struct tap_dev __rcu
*tap` in `struct tap_queue`, which makes the uid of all tap sockets 0,
i.e., the root one.
Fix the assignment by using sock_init_data_uid( ). Fixes: 86741ec25462 ("net: core: Add a UID field to struct sock.")
Signed-off-by: Pietro Borrello <email address hidden>
Reviewed-by: Eric Dumazet <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit 66b2c338adce580dfce2199591e65e 2bab889cff)
CVE-2023-1076
Signed-off-by: Cengiz Can <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>