~ubuntu-kernel/ubuntu/+source/linux/+git/focal:master-next--s2024.04.01-1

Branch merges

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related charm recipes

8b5f7ab... by Johannes Berg on 2024-04-12

wifi: mac80211: fix potential key use-after-free

When ieee80211_key_link() is called by ieee80211_gtk_rekey_add()
but returns 0 due to KRACK protection (identical key reinstall),
ieee80211_gtk_rekey_add() will still return a pointer into the
key, in a potential use-after-free. This normally doesn't happen
since it's only called by iwlwifi in case of WoWLAN rekey offload
which has its own KRACK protection, but still better to fix, do
that by returning an error code and converting that to success on
the cfg80211 boundary only, leaving the error for bad callers of
ieee80211_gtk_rekey_add().

Reported-by: Dan Carpenter <email address hidden>
Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything")
Signed-off-by: Johannes Berg <email address hidden>
(backported from commit 31db78a4923ef5e2008f2eed321811ca79e7f71b)
[bjamison: context conflict - added KRACK protection as written in the fix
commit since the context conflict was with a neighboring line that doesn't
affect the fix commit]
CVE-2023-52530
Signed-off-by: Bethany Jamison <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Acked-by: Roxana Nicolescu <email address hidden>
Acked-by: Andrei Gherzan <email address hidden>
Signed-off-by: Roxana Nicolescu <email address hidden>

e6398fb... by Tetsuo Handa <email address hidden> on 2024-04-01

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 2f03fc340cac9ea1dc63cbf8c93dd2eb0f227815)
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>

77b8260... by Zhengchao Shao <email address hidden> on 2024-04-10

ipv6: init the accept_queue's spinlocks in inet6_create

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: 00007ffdae45c6e0

Fixes: 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>
(cherry picked from commit 435e202d645c197dcfd39d7372eb2a56529b6640)
CVE-2024-26614
Signed-off-by: Bethany Jamison <email address hidden>
Acked-by: Jacob Martin <email address hidden>
Acked-by: Andrei Gherzan <email address hidden>
Signed-off-by: Roxana Nicolescu <email address hidden>

66cb7d9... by Zhengchao Shao <email address hidden> on 2024-04-10

tcp: make sure init the accept_queue's spinlocks once

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:ffff9d1ef60c0000(0000) knlGS:0000000000000000
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>
(backported from commit 198bc90e0e734e5f98c3d2833e8390cac3df61b2)
[bjamison: context conflict because upstream had a function in the h file that
Focal didn't have, I added the function from the fix commit]
CVE-2024-26614
Signed-off-by: Bethany Jamison <email address hidden>
Acked-by: Jacob Martin <email address hidden>
Acked-by: Andrei Gherzan <email address hidden>
Signed-off-by: Roxana Nicolescu <email address hidden>

7a90704... by Zheng Wang <zyytlz.wz@163.com> on 2024-04-03

wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach

This is the candidate patch of CVE-2023-47233 :
https://nvd.nist.gov/vuln/detail/CVE-2023-47233

In brcm80211 driver,it starts with the following invoking chain
to start init a timeout worker:

->brcmf_usb_probe
  ->brcmf_usb_probe_cb
    ->brcmf_attach
      ->brcmf_bus_started
        ->brcmf_cfg80211_attach
          ->wl_init_priv
            ->brcmf_init_escan
              ->INIT_WORK(&cfg->escan_timeout_work,
    brcmf_cfg80211_escan_timeout_worker);

If we disconnect the USB by hotplug, it will call
brcmf_usb_disconnect to make cleanup. The invoking chain is :

brcmf_usb_disconnect
  ->brcmf_usb_disconnect_cb
    ->brcmf_detach
      ->brcmf_cfg80211_detach
        ->kfree(cfg);

While the timeout woker may still be running. This will cause
a use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker.

Fix it by deleting the timer and canceling the worker in
brcmf_cfg80211_detach.

Fixes: e756af5b30b0 ("brcmfmac: add e-scan support.")
Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
Cc: <email address hidden>
[<email address hidden>: keep timer delete as is and cancel work just before free]
Signed-off-by: Arend van Spriel <email address hidden>
Signed-off-by: Kalle Valo <email address hidden>
Link: https://<email address hidden>
(backported from commit 0f7352557a35ab7888bc7831411ec8a3cbe20d78)
[bjamison: use del_timer_sync instead of timer_delete_sync]
CVE-2023-47233
Signed-off-by: Bethany Jamison <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Acked-by: Roxana Nicolescu <email address hidden>
Signed-off-by: Roxana Nicolescu <email address hidden>

7932ab8... by Roxana Nicolescu on 2024-03-28

UBUNTU: Ubuntu-5.4.0-181.201

Signed-off-by: Roxana Nicolescu <email address hidden>

d7fdcd3... by Roxana Nicolescu on 2024-03-28

UBUNTU: link-to-tracker: update tracking bug

BugLink: https://bugs.launchpad.net/bugs/2059549
Properties: no-test-build
Signed-off-by: Roxana Nicolescu <email address hidden>

8a08702... by Roxana Nicolescu on 2024-03-28

UBUNTU: [Packaging] drop getabis data

BugLink: https://bugs.launchpad.net/bugs/1786013
Signed-off-by: Roxana Nicolescu <email address hidden>

c58a8c7... by Magali Lemes do Sacramento on 2024-03-26

UBUNTU: [Packaging] Remove fips-checks script

BugLink: https://bugs.launchpad.net/bugs/2055083

This script is now part of `cranky` and there is no need for it to live
in debian/ anymore, so remove it.

Signed-off-by: Magali Lemes <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Roxana Nicolescu <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>

fb798d5... by Roxana Nicolescu on 2024-03-26

UBUNTU: [Packaging] Remove getabis

BugLink: https://bugs.launchpad.net/bugs/2059143

With ABI checks removed from the tree (#LP2055685), there's no need to
download the buildinfo from a previous version.

Signed-off-by: Roxana Nicolescu <email address hidden>
Acked-by: Andrea Righi <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>