~ubuntu-kernel/ubuntu/+source/linux/+git/mantic:master-next--s2024.04.01-1
- Git
- lp:~ubuntu-kernel/ubuntu/+source/linux/+git/mantic
- master-next--s2024.04.01-1
- Get this branch:
-
git clone
-b master-next--s2024.04.01-1
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/mantic
Branch merges
Related source package recipes
Branch information
- Name:
- master-next--s2024.04.01-1
Recent commits
- 4d2126d... by Matthew Ruffell
-
UBUNTU: SAUCE: Revert "cifs: fix flushing folio regression for 6.1 backport"
BugLink: https:/
/bugs.launchpad .net/bugs/ 2060919 This reverts commit 21bb2ba4f1ac1e3
a57594be62dd74e 7b1401b2b1 (ubuntu-mantic). __filemap_
get_folio( ) works differently in 6.1.y where the patch was initially
sourced from, to mantic's 6.5 kernel. In 6.1.y, it returns a folio or NULL,
and in 6.5, it returns a folio or negative error code.With this applied to mantic's 6.5, users would see page faults when attempting
to copy or write to a file from the same directory as the source.BUG: unable to handle page fault for address: fffffffffffffffe
...
RIP: 0010:cifs_flush_folio+ 0x41/0xf0 [cifs]
...
Call Trace:
<TASK>
? show_regs+0x6d/0x80
? __die+0x24/0x80
? page_fault_oops+0x99/ 0x1b0
? kernelmode_fixup_or_ oops+0xb2/ 0x140
? __bad_area_nosemaphore+ 0x1a5/0x2c0
? bad_area_nosemaphore+ 0x16/0x30
? do_kern_addr_fault+ 0x7b/0xa0
? exc_page_fault+0x1a4/ 0x1b0
? asm_exc_page_fault+ 0x27/0x30
? cifs_flush_folio+0x41/ 0xf0 [cifs]
? cifs_flush_folio+0x37/ 0xf0 [cifs]
cifs_remap_file_range+ 0x172/0x660 [cifs]
do_clone_file_range+ 0x101/0x2d0
vfs_clone_file_range+ 0x3f/0x150
ioctl_file_clone+0x52/ 0xc0
do_vfs_ioctl+0x68f/ 0x910
..."cifs: fix flushing folio regression for 6.1 backport" should have never been
applied to mantic's tree, thus we revert it as a SAUCE patch.Signed-off-by: Matthew Ruffell <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Roxana Nicolescu <email address hidden>
Signed-off-by: Roxana Nicolescu <email address hidden> - 9cd80dc... by Ryosuke Yasuoka <email address hidden>
-
netlink: Fix kernel-
infoleak- after-free in __skb_datagram_iter [ Upstream commit 661779e1fcafe1b
74b3f3fe8e980c1 e207fea1fd ] syzbot reported the following uninit-value access issue [1]:
netlink_
to_full_ skb() creates a new `skb` and puts the `skb->data`
passed as a 1st arg of netlink_to_full_ skb() onto new `skb`. The data
size is specified as `len` and passed to skb_put_data(). This `len`
is based on `skb->end` that is not data offset but buffer offset. The
`skb->end` contains data and tailroom. Since the tailroom is not
initialized when the new `skb` created, KMSAN detects uninitialized
memory area when copying the data.This patch resolved this issue by correct the len from `skb->end` to
`skb->len`, which is the actual data offset.BUG: KMSAN: kernel-
infoleak- after-free in instrument_ copy_to_ user include/ linux/instrumen ted.h:114 [inline]
BUG: KMSAN: kernel-infoleak- after-free in copy_to_user_iter lib/iov_iter.c:24 [inline]
BUG: KMSAN: kernel-infoleak- after-free in iterate_ubuf include/ linux/iov_ iter.h: 29 [inline]
BUG: KMSAN: kernel-infoleak- after-free in iterate_ and_advance2 include/ linux/iov_ iter.h: 245 [inline]
BUG: KMSAN: kernel-infoleak- after-free in iterate_and_advance include/ linux/iov_ iter.h: 271 [inline]
BUG: KMSAN: kernel-infoleak- after-free in _copy_to_ iter+0x364/ 0x2520 lib/iov_iter.c:186
instrument_copy_to_ user include/ linux/instrumen ted.h:114 [inline]
copy_to_user_iter lib/iov_iter.c:24 [inline]
iterate_ubuf include/linux/iov_ iter.h: 29 [inline]
iterate_and_advance2 include/ linux/iov_ iter.h: 245 [inline]
iterate_and_advance include/ linux/iov_ iter.h: 271 [inline]
_copy_to_iter+ 0x364/0x2520 lib/iov_iter.c:186
copy_to_iter include/linux/uio. h:197 [inline]
simple_copy_to_ iter+0x68/ 0xa0 net/core/ datagram. c:532
__skb_datagram_ iter+0x123/ 0xdc0 net/core/ datagram. c:420
skb_copy_datagram_ iter+0x5c/ 0x200 net/core/ datagram. c:546
skb_copy_datagram_ msg include/ linux/skbuff. h:3960 [inline]
packet_recvmsg+ 0xd9c/0x2000 net/packet/ af_packet. c:3482
sock_recvmsg_nosec net/socket.c:1044 [inline]
sock_recvmsg net/socket.c:1066 [inline]
sock_read_iter+0x467/ 0x580 net/socket.c:1136
call_read_iter include/linux/fs. h:2014 [inline]
new_sync_read fs/read_write.c:389 [inline]
vfs_read+0x8f6/0xe00 fs/read_write.c:470
ksys_read+0x20f/0x4c0 fs/read_write.c:613
__do_sys_read fs/read_write.c:623 [inline]
__se_sys_read fs/read_write.c:621 [inline]
__x64_sys_read+ 0x93/0xd0 fs/read_write.c:621
do_syscall_x64 arch/x86/entry/common. c:52 [inline]
do_syscall_64+0x44/ 0x110 arch/x86/ entry/common. c:83
entry_SYSCALL_ 64_after_ hwframe+ 0x63/0x6b Uninit was stored to memory at:
skb_put_data include/linux/skbuff. h:2622 [inline]
netlink_to_full_ skb net/netlink/ af_netlink. c:181 [inline]
__netlink_deliver_ tap_skb net/netlink/ af_netlink. c:298 [inline]
__netlink_deliver_ tap+0x5be/ 0xc90 net/netlink/ af_netlink. c:325
netlink_deliver_ tap net/netlink/ af_netlink. c:338 [inline]
netlink_deliver_ tap_kernel net/netlink/ af_netlink. c:347 [inline]
netlink_unicast_ kernel net/netlink/ af_netlink. c:1341 [inline]
netlink_unicast+ 0x10f1/ 0x1250 net/netlink/ af_netlink. c:1368
netlink_sendmsg+ 0x1238/ 0x13d0 net/netlink/ af_netlink. c:1910
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
____sys_sendmsg+ 0x9c2/0xd60 net/socket.c:2584
___sys_sendmsg+ 0x28d/0x3c0 net/socket.c:2638
__sys_sendmsg net/socket.c:2667 [inline]
__do_sys_sendmsg net/socket.c:2676 [inline]
__se_sys_sendmsg net/socket.c:2674 [inline]
__x64_sys_sendmsg+ 0x307/0x490 net/socket.c:2674
do_syscall_x64 arch/x86/entry/common. c:52 [inline]
do_syscall_64+0x44/ 0x110 arch/x86/ entry/common. c:83
entry_SYSCALL_ 64_after_ hwframe+ 0x63/0x6b Uninit was created at:
free_pages_prepare mm/page_alloc.c: 1087 [inline]
free_unref_page_prepare+ 0xb0/0xa40 mm/page_ alloc.c: 2347
free_unref_page_list+ 0xeb/0x1100 mm/page_ alloc.c: 2533
release_pages+0x23d3/ 0x2410 mm/swap.c:1042
free_pages_and_swap_ cache+0xd9/ 0xf0 mm/swap_state.c:316
tlb_batch_pages_flush mm/mmu_gather.c:98 [inline]
tlb_flush_mmu_free mm/mmu_gather.c:293 [inline]
tlb_flush_mmu+0x6f5/ 0x980 mm/mmu_gather.c:300
tlb_finish_mmu+0x101/ 0x260 mm/mmu_gather.c:392
exit_mmap+0x49e/0xd30 mm/mmap.c:3321
__mmput+0x13f/0x530 kernel/fork.c:1349
mmput+0x8a/0xa0 kernel/fork.c:1371
exit_mm+0x1b8/0x360 kernel/exit.c:567
do_exit+0xd57/0x4080 kernel/exit.c:858
do_group_exit+0x2fd/ 0x390 kernel/exit.c:1021
__do_sys_exit_group kernel/exit.c:1032 [inline]
__se_sys_exit_group kernel/exit.c:1030 [inline]
__x64_sys_exit_ group+0x3c/ 0x50 kernel/exit.c:1030
do_syscall_x64 arch/x86/entry/common. c:52 [inline]
do_syscall_64+0x44/ 0x110 arch/x86/ entry/common. c:83
entry_SYSCALL_ 64_after_ hwframe+ 0x63/0x6b Bytes 3852-3903 of 3904 are uninitialized
Memory access of size 3904 starts at ffff88812ea1e000
Data copied to user address 0000000020003280CPU: 1 PID: 5043 Comm: syz-executor297 Not tainted 6.7.0-rc5-
syzkaller- 00047-g5bd7ef53 ffe5 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023Fixes: 1853c9496460 ("netlink, mmap: transform mmap skb into full skb on taps")
Reported-and-tested- by: <email address hidden>
Closes: https://syzkaller. appspot. com/bug? extid=34ad5fab4 8f7bf510349 [1]
Signed-off-by: Ryosuke Yasuoka <email address hidden>
Reviewed-by: Eric Dumazet <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Jakub Kicinski <email address hidden>
Signed-off-by: Sasha Levin <email address hidden>
(cherry picked from commit d3ada42e534a83b618bbc1e490d23b f0fdae4736 linux-6.6.y)
CVE-2024-26805
Signed-off-by: Bethany Jamison <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Roxana Nicolescu <email address hidden>
Signed-off-by: Roxana Nicolescu <email address hidden> - 13145c9... by Ying Hsu <email address hidden>
-
Bluetooth: Avoid potential use-after-free in hci_error_reset
[ Upstream commit 2449007d3f73b28
42c9734f45f0aad b522daf592 ] While handling the HCI_EV_
HARDWARE_ ERROR event, if the underlying
BT controller is not responding, the GPIO reset mechanism would
free the hci_dev and lead to a use-after-free in hci_error_reset.Here's the call trace observed on a ChromeOS device with Intel AX201:
queue_work_on+ 0x3e/0x6c
__hci_cmd_sync_ sk+0x2ee/ 0x4c0 [bluetooth <HASH:3b4a6>]
? init_wait_entry+0x31/ 0x31
__hci_cmd_sync+ 0x16/0x20 [bluetooth <HASH:3b4a 6>]
hci_error_reset+ 0x4f/0xa4 [bluetooth <HASH:3b4a 6>]
process_one_work+ 0x1d8/0x33f
worker_thread+ 0x21b/0x373
kthread+0x13a/0x152
? pr_cont_work+0x54/ 0x54
? kthread_blkcg+0x31/ 0x31
ret_from_fork+ 0x1f/0x30 This patch holds the reference count on the hci_dev while processing
a HCI_EV_HARDWARE_ ERROR event to avoid potential crash. Fixes: c7741d16a57c ("Bluetooth: Perform a power cycle when receiving hardware error event")
Signed-off-by: Ying Hsu <email address hidden>
Signed-off-by: Luiz Augusto von Dentz <email address hidden>
Signed-off-by: Sasha Levin <email address hidden>
(cherry picked from commit 2ab9a19d896f5a0dd386e1f001c530 9bc35f433b linux-6.6.y)
CVE-2024-26801
Signed-off-by: Bethany Jamison <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Roxana Nicolescu <email address hidden>
Signed-off-by: Roxana Nicolescu <email address hidden> - 3228aee... by Baokun Li <email address hidden>
-
ext4: fix double-free of blocks due to wrong extents moved_len
RefLink: https:/
/bugs.launchpad .net/bugs/ 2061814 commit 55583e899a53573
08274601364741a 83e78d6ac4 upstream. In ext4_move_
extents( ), moved_len is only updated when all moves are
successfully executed, and only discards orig_inode and donor_inode
preallocations when moved_len is not zero. When the loop fails to exit
after successfully moving some extents, moved_len is not updated and
remains at 0, so it does not discard the preallocations.If the moved extents overlap with the preallocated extents, the
overlapped extents are freed twice in ext4_mb_release_ inode_pa( ) and
ext4_process_freed_data( ) (as described in commit 94d7c16cbbbd ("ext4:
Fix double-free of blocks with EXT4_IOC_MOVE_EXT" )), and bb_free is
incremented twice. Hence when trim is executed, a zero-division bug is
triggered in mb_update_avg_fragment_ size() because bb_free is not zero
and bb_fragments is zero.Therefore, update move_len after each extent move to avoid the issue.
Reported-by: Wei Chen <email address hidden>
Reported-by: xingwei lee <email address hidden>
Closes: https://lore.<email address hidden>
Fixes: fcf6b1b729bc ("ext4: refactor ext4_move_extents code base")
CC: <email address hidden> # 3.18
Signed-off-by: Baokun Li <email address hidden>
Reviewed-by: Jan Kara <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Theodore Ts'o <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
CVE-2024-26704
Signed-off-by: Portia Stephens <email address hidden>
Signed-off-by: Roxana Nicolescu <email address hidden> - 810dc33... by Manas Ghandat <email address hidden>
-
jfs: fix array-index-
out-of- bounds in dbAdjTree RefLink: https:/
/bugs.launchpad .net/bugs/ 2059284 [ Upstream commit 74ecdda68242b17
4920fe7c6133a85 6fb7d8559b ] Currently there is a bound check missing in the dbAdjTree while
accessing the dmt_stree. To add the required check added the bool is_ctl
which is required to determine the size as suggest in the following
commit.
https://lore.kernel<email address hidden>/ Reported-by: <email address hidden>
Closes: https://syzkaller. appspot. com/bug? extid=39ba34a09 9ac2e9bd3cb
Signed-off-by: Manas Ghandat <email address hidden>
Signed-off-by: Dave Kleikamp <email address hidden>
Signed-off-by: Sasha Levin <email address hidden>CVE-2023-52601
Signed-off-by: Manuel Diewald <email address hidden>
Signed-off-by: Stefan Bader <email address hidden> - d1f19bd... by Kuniyuki Iwashima <email address hidden>
-
llc: Drop support for ETH_P_TR_802_2.
RefLink: https:/
/bugs.launchpad .net/bugs/ 2059068 [ Upstream commit e3f9bed9bee261e
3347131764e42ae edf1ffea61 ] syzbot reported an uninit-value bug below. [0]
llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2
(0x0011), and syzbot abused the latter to trigger the bug.write$tun(r0, &(0x7f000000004
0)={@val= {0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd"}}}}, 0x16) llc_conn_handler() initialises local variables {saddr,daddr}.mac
based on skb in llc_pdu_decode_ sa()/llc_ pdu_decode_ da() and passes
them to __llc_lookup().However, the initialisation is done only when skb->protocol is
htons(ETH_P_802_2), otherwise, __llc_lookup_established( ) and
__llc_lookup_listener( ) will read garbage. The missing initialisation existed prior to commit 211ed865108e
("net: delete all instances of special processing for token ring").It removed the part to kick out the token ring stuff but forgot to
close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().Let's remove llc_tr_packet_type and complete the deprecation.
[0]:
BUG: KMSAN: uninit-value in __llc_lookup_established+ 0xe9d/0xf90
__llc_lookup_ established+ 0xe9d/0xf90
__llc_lookup net/llc/llc_conn. c:611 [inline]
llc_conn_handler+ 0x4bd/0x1360 net/llc/ llc_conn. c:791
llc_rcv+0xfbb/0x14a0 net/llc/ llc_input. c:206
__netif_receive_ skb_one_ core net/core/dev.c:5527 [inline]
__netif_receive_ skb+0x1a6/ 0x5a0 net/core/dev.c:5641
netif_receive_ skb_internal net/core/dev.c:5727 [inline]
netif_receive_ skb+0x58/ 0x660 net/core/dev.c:5786
tun_rx_batched+ 0x3ee/0x980 drivers/ net/tun. c:1555
tun_get_user+0x53af/ 0x66d0 drivers/ net/tun. c:2002
tun_chr_write_iter+ 0x3af/0x5d0 drivers/ net/tun. c:2048
call_write_iter include/linux/fs. h:2020 [inline]
new_sync_write fs/read_write.c:491 [inline]
vfs_write+0x8ef/0x1490 fs/read_write.c:584
ksys_write+0x20f/0x4c0 fs/read_write.c:637
__do_sys_write fs/read_write.c:649 [inline]
__se_sys_write fs/read_write.c:646 [inline]
__x64_sys_write+ 0x93/0xd0 fs/read_write.c:646
do_syscall_x64 arch/x86/entry/common. c:51 [inline]
do_syscall_64+0x44/ 0x110 arch/x86/ entry/common. c:82
entry_SYSCALL_ 64_after_ hwframe+ 0x63/0x6b Local variable daddr created at:
llc_conn_handler+ 0x53/0x1360 net/llc/ llc_conn. c:783
llc_rcv+0xfbb/0x14a0 net/llc/ llc_input. c:206 CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller
-14500- g1c41041124bd #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023Fixes: 211ed865108e ("net: delete all instances of special processing for token ring")
Reported-by: <email address hidden>
Closes: https://syzkaller. appspot. com/bug? extid=b5ad66046 b913bc04c6f
Signed-off-by: Kuniyuki Iwashima <email address hidden>
Reviewed-by: Eric Dumazet <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Jakub Kicinski <email address hidden>
Signed-off-by: Sasha Levin <email address hidden>CVE-2024-26635
Signed-off-by: Portia Stephens <email address hidden>
Signed-off-by: Stefan Bader <email address hidden> - 3d401fb... by Tetsuo Handa <email address hidden>
-
tomoyo: fix UAF write bug in tomoyo_
write_control( ) Since tomoyo_
write_control( ) updates head->write_buf when write()
of long lines is requested, we need to fetch head->write_buf after
head->io_sem is held. Otherwise, concurrent write() requests can
cause use-after-free-write and double-free problems. Reported-by: Sam Sun <email address hidden>
Closes: https://lkml.<email address hidden>
Fixes: bd03a3e4c9a9 ("TOMOYO: Add policy namespace support.")
Cc: <email address hidden> # Linux 3.1+
Signed-off-by: Tetsuo Handa <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>CVE-2024-26622
(cherry picked from commit 2f03fc340cac9ea1dc63cbf8c93dd2 eb0f227815)
Signed-off-by: Bethany Jamison <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Acked-by: Andrei Gherzan <email address hidden>
Signed-off-by: Roxana Nicolescu <email address hidden> - 720e259... by Zhengchao Shao <email address hidden>
-
ipv6: init the accept_queue's spinlocks in inet6_create
RefLink: https:/
/bugs.launchpad .net/bugs/ 2059068 [ Upstream commit 435e202d645c197
dcfd39d7372eb2a 56529b6640 ] In commit 198bc90e0e73("tcp: make sure init the accept_queue's spinlocks
once"), the spinlocks of accept_queue are initialized only when socket is
created in the inet4 scenario. The locks are not initialized when socket
is created in the inet6 scenario. The kernel reports the following error:
INFO: trying to register non-static key.
The code is fine but needs lockdep annotation, or maybe
you didn't initialize this object before use?
turning off the locking correctness validator.
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
Call Trace:
<TASK>
dump_stack_lvl (lib/dump_stack.c: 107)
register_lock_class (kernel/ locking/ lockdep. c:1289)
__lock_acquire (kernel/locking/ lockdep. c:5015)
lock_acquire.part.0 (kernel/ locking/ lockdep. c:5756)
_raw_spin_lock_bh (kernel/locking/ spinlock. c:178)
inet_csk_listen_ stop (net/ipv4/ inet_connection _sock.c: 1386)
tcp_disconnect (net/ipv4/tcp.c:2981)
inet_shutdown (net/ipv4/af_inet. c:935)
__sys_shutdown (./include/linux/file. h:32 net/socket.c:2438)
__x64_sys_shutdown (net/socket.c:2445)
do_syscall_64 (arch/x86/entry/common. c:52)
entry_SYSCALL_ 64_after_ hwframe (arch/x86/ entry/entry_ 64.S:129)
RIP: 0033:0x7f52ecd05a3d
Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 73 01 c3 48 8b 0d ab a3 0e 00 f7 d8 64 89 01 48
RSP: 002b:00007f52ecf5dde8 EFLAGS: 00000293 ORIG_RAX: 0000000000000030
RAX: ffffffffffffffda RBX: 00007f52ecf5e640 RCX: 00007f52ecd05a3d
RDX: 00007f52ecc8b188 RSI: 0000000000000000 RDI: 0000000000000004
RBP: 00007f52ecf5de20 R08: 00007ffdae45c69f R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000293 R12: 00007f52ecf5e640
R13: 0000000000000000 R14: 00007f52ecc8b060 R15: 00007ffdae45c6e0Fixes: 198bc90e0e73 ("tcp: make sure init the accept_queue's spinlocks once")
Signed-off-by: Zhengchao Shao <email address hidden>
Reviewed-by: Eric Dumazet <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Paolo Abeni <email address hidden>
Signed-off-by: Sasha Levin <email address hidden>CVE-2024-26614
Signed-off-by: Portia Stephens <email address hidden>
Signed-off-by: Stefan Bader <email address hidden> - f014510... by Zhengchao Shao <email address hidden>
-
tcp: make sure init the accept_queue's spinlocks once
RefLink: https:/
/bugs.launchpad .net/bugs/ 2059068 [ Upstream commit 198bc90e0e734e5
f98c3d2833e8390 cac3df61b2 ] When I run syz's reproduction C program locally, it causes the following
issue:
pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0!
WARNING: CPU: 19 PID: 21160 at __pv_queued_spin_unlock_ slowpath (kernel/ locking/ qspinlock_ paravirt. h:508)
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
RIP: 0010:__pv_queued_ spin_unlock_ slowpath (kernel/ locking/ qspinlock_ paravirt. h:508)
Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7
30 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90
RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908
RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900
RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff
R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000
R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000
FS: 00007fa110184640(0000) GS:ffff9d1ef60c 0000(0000) knlGS:000000000 0000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0
Call Trace:
<IRQ>
_raw_spin_unlock (kernel/locking/ spinlock. c:186)
inet_csk_reqsk_ queue_add (net/ipv4/ inet_connection _sock.c: 1321)
inet_csk_complete_ hashdance (net/ipv4/ inet_connection _sock.c: 1358)
tcp_check_req (net/ipv4/tcp_minisocks. c:868)
tcp_v4_rcv (net/ipv4/tcp_ipv4. c:2260)
ip_protocol_deliver_ rcu (net/ipv4/ ip_input. c:205)
ip_local_deliver_ finish (net/ipv4/ ip_input. c:234)
__netif_receive_ skb_one_ core (net/core/ dev.c:5529)
process_backlog (./include/linux/rcupdate. h:779)
__napi_poll (net/core/dev.c:6533)
net_rx_action (net/core/dev.c:6604)
__do_softirq (./arch/x86/include/ asm/jump_ label.h: 27)
do_softirq (kernel/softirq. c:454 kernel/ softirq. c:441)
</IRQ>
<TASK>
__local_bh_enable_ ip (kernel/ softirq. c:381)
__dev_queue_xmit (net/core/dev.c:4374)
ip_finish_output2 (./include/net/neighbour. h:540 net/ipv4/ ip_output. c:235)
__ip_queue_xmit (net/ipv4/ip_output. c:535)
__tcp_transmit_ skb (net/ipv4/ tcp_output. c:1462)
tcp_rcv_synsent_ state_process (net/ipv4/ tcp_input. c:6469)
tcp_rcv_state_process (net/ipv4/ tcp_input. c:6657)
tcp_v4_do_rcv (net/ipv4/tcp_ipv4. c:1929)
__release_sock (./include/net/sock. h:1121 net/core/ sock.c: 2968)
release_sock (net/core/sock.c: 3536)
inet_wait_for_ connect (net/ipv4/ af_inet. c:609)
__inet_stream_ connect (net/ipv4/ af_inet. c:702)
inet_stream_ connect (net/ipv4/ af_inet. c:748)
__sys_connect (./include/linux/file. h:45 net/socket.c:2064)
__x64_sys_connect (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070)
do_syscall_64 (arch/x86/entry/common. c:51 arch/x86/ entry/common. c:82)
entry_SYSCALL_ 64_after_ hwframe (arch/x86/ entry/entry_ 64.S:129)
RIP: 0033:0x7fa10ff05a3d
Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89
c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ab a3 0e 00 f7 d8 64 89 01 48
RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 0000000020000054 RCX: 00007fa10ff05a3d
RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003
RBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 00007fa110184640
R13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20
</TASK>The issue triggering process is analyzed as follows:
Thread A Thread B
tcp_v4_rcv //receive ack TCP packet inet_shutdown
tcp_check_req tcp_disconnect //disconnect sock
... tcp_set_state(sk, TCP_CLOSE)
inet_csk_complete_ hashdance ...
inet_csk_reqsk_ queue_add inet_listen //start listen
spin_lock( &queue- >rskq_lock) inet_csk_ listen_ start
... reqsk_queue_alloc
... spin_lock_init
spin_unlock( &queue- >rskq_lock) //warning When the socket receives the ACK packet during the three-way handshake,
it will hold spinlock. And then the user actively shutdowns the socket
and listens to the socket immediately, the spinlock will be initialized.
When the socket is going to release the spinlock, a warning is generated.
Also the same issue to fastopenq.lock.Move init spinlock to inet_create and inet_accept to make sure init the
accept_queue's spinlocks once.Fixes: fff1f3001cc5 ("tcp: add a spinlock to protect struct request_
sock_queue" )
Fixes: 168a8f58059a ("tcp: TCP Fast Open Server - main code path")
Reported-by: Ming Shu <email address hidden>
Signed-off-by: Zhengchao Shao <email address hidden>
Reviewed-by: Eric Dumazet <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Jakub Kicinski <email address hidden>
Signed-off-by: Sasha Levin <email address hidden>CVE-2024-26614
Signed-off-by: Portia Stephens <email address hidden>
Signed-off-by: Stefan Bader <email address hidden> - d7ec3ee... by Herbert Xu
-
hwrng: core - Fix page fault dead lock on mmap-ed hwrng
RefLink: https:/
/bugs.launchpad .net/bugs/ 2059068 commit 78aafb3884f6bc6
636efcc1760c891 c8500b9922 upstream. There is a dead-lock in the hwrng device read path. This triggers
when the user reads from /dev/hwrng into memory also mmap-ed from
/dev/hwrng. The resulting page fault triggers a recursive read
which then dead-locks.Fix this by using a stack buffer when calling copy_to_user.
Reported-by: Edward Adam Davis <email address hidden>
Reported-by: <email address hidden>
Fixes: 9996508b3353 ("hwrng: core - Replace u32 in driver API with byte array")
Cc: <email address hidden>
Signed-off-by: Herbert Xu <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>CVE-2024-52615
Signed-off-by: Portia Stephens <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>