Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netrom: Fix a memory leak in nr_heartbeat_expiry()<br /> <br /> syzbot reported a memory leak in nr_create() [0].<br /> <br /> Commit 409db27e3a2e ("netrom: Fix use-after-free of a listening socket.")<br /> added sock_hold() to the nr_heartbeat_expiry() function, where<br /> a) a socket has a SOCK_DESTROY flag or<br /> b) a listening socket has a SOCK_DEAD flag.<br /> <br /> But in the case "a," when the SOCK_DESTROY flag is set, the file descriptor<br /> has already been closed and the nr_release() function has been called.<br /> So it makes no sense to hold the reference count because no one will<br /> call another nr_destroy_socket() and put it as in the case "b."<br /> <br /> nr_connect<br /> nr_establish_data_link<br /> nr_start_heartbeat<br /> <br /> nr_release<br /> switch (nr-&gt;state)<br /> case NR_STATE_3<br /> nr-&gt;state = NR_STATE_2<br /> sock_set_flag(sk, SOCK_DESTROY);<br /> <br /> nr_rx_frame<br /> nr_process_rx_frame<br /> switch (nr-&gt;state)<br /> case NR_STATE_2<br /> nr_state2_machine()<br /> nr_disconnect()<br /> nr_sk(sk)-&gt;state = NR_STATE_0<br /> sock_set_flag(sk, SOCK_DEAD)<br /> <br /> nr_heartbeat_expiry<br /> switch (nr-&gt;state)<br /> case NR_STATE_0<br /> if (sock_flag(sk, SOCK_DESTROY) ||<br /> (sk-&gt;sk_state == TCP_LISTEN<br /> &amp;&amp; sock_flag(sk, SOCK_DEAD)))<br /> sock_hold() // ( !!! )<br /> nr_destroy_socket()<br /> <br /> To fix the memory leak, let&amp;#39;s call sock_hold() only for a listening socket.<br /> <br /> Found by InfoTeCS on behalf of Linux Verification Center<br /> (linuxtesting.org) with Syzkaller.<br /> <br /> [0]: https://syzkaller.appspot.com/bug?extid=d327a1f3b12e1e206c16

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/tcp_ao: Don&amp;#39;t leak ao_info on error-path<br /> <br /> It seems I introduced it together with TCP_AO_CMDF_AO_REQUIRED, on<br /> version 5 [1] of TCP-AO patches. Quite frustrative that having all these<br /> selftests that I&amp;#39;ve written, running kmemtest &amp; kcov was always in todo.<br /> <br /> [1]: https://lore.kernel.org/netdev/20230215183335.800122-5-dima@arista.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: xilinx: xdma: Fix data synchronisation in xdma_channel_isr()<br /> <br /> Requests the vchan lock before using xdma-&gt;stop_request.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: ti: k3-udma-glue: Fix of_k3_udma_glue_parse_chn_by_id()<br /> <br /> The of_k3_udma_glue_parse_chn_by_id() helper function erroneously<br /> invokes "of_node_put()" on the "udmax_np" device-node passed to it,<br /> without having incremented its reference count at any point. Fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix responder length checking for UD request packets<br /> <br /> According to the IBA specification:<br /> If a UD request packet is detected with an invalid length, the request<br /> shall be an invalid request and it shall be silently dropped by<br /> the responder. The responder then waits for a new request packet.<br /> <br /> commit 689c5421bfe0 ("RDMA/rxe: Fix incorrect responder length checking")<br /> defers responder length check for UD QPs in function `copy_data`.<br /> But it introduces a regression issue for UD QPs.<br /> <br /> When the packet size is too large to fit in the receive buffer.<br /> `copy_data` will return error code -EINVAL. Then `send_data_in`<br /> will return RESPST_ERR_MALFORMED_WQE. UD QP will transfer into<br /> ERROR state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: amd-pstate: fix memory leak on CPU EPP exit<br /> <br /> The cpudata memory from kzalloc() in amd_pstate_epp_cpu_init() is<br /> not freed in the analogous exit function, so fix that.<br /> <br /> [ rjw: Subject and changelog edits ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix uninitialized ratelimit_state-&gt;lock access in __ext4_fill_super()<br /> <br /> In the following concurrency we will access the uninitialized rs-&gt;lock:<br /> <br /> ext4_fill_super<br /> ext4_register_sysfs<br /> // sysfs registered msg_ratelimit_interval_ms<br /> // Other processes modify rs-&gt;interval to<br /> // non-zero via msg_ratelimit_interval_ms<br /> ext4_orphan_cleanup<br /> ext4_msg(sb, KERN_INFO, "Errors on filesystem, "<br /> __ext4_msg<br /> ___ratelimit(&amp;(EXT4_SB(sb)-&gt;s_msg_ratelimit_state)<br /> if (!rs-&gt;interval) // do nothing if interval is 0<br /> return 1;<br /> raw_spin_trylock_irqsave(&amp;rs-&gt;lock, flags)<br /> raw_spin_trylock(lock)<br /> _raw_spin_trylock<br /> __raw_spin_trylock<br /> spin_acquire(&amp;lock-&gt;dep_map, 0, 1, _RET_IP_)<br /> lock_acquire<br /> __lock_acquire<br /> register_lock_class<br /> assign_lock_key<br /> dump_stack();<br /> ratelimit_state_init(&amp;sbi-&gt;s_msg_ratelimit_state, 5 * HZ, 10);<br /> raw_spin_lock_init(&amp;rs-&gt;lock);<br /> // init rs-&gt;lock here<br /> <br /> and get the following dump_stack:<br /> <br /> =========================================================<br /> INFO: trying to register non-static key.<br /> The code is fine but needs lockdep annotation, or maybe<br /> you didn&amp;#39;t initialize this object before use?<br /> turning off the locking correctness validator.<br /> CPU: 12 PID: 753 Comm: mount Tainted: G E 6.7.0-rc6-next-20231222 #504<br /> [...]<br /> Call Trace:<br /> dump_stack_lvl+0xc5/0x170<br /> dump_stack+0x18/0x30<br /> register_lock_class+0x740/0x7c0<br /> __lock_acquire+0x69/0x13a0<br /> lock_acquire+0x120/0x450<br /> _raw_spin_trylock+0x98/0xd0<br /> ___ratelimit+0xf6/0x220<br /> __ext4_msg+0x7f/0x160 [ext4]<br /> ext4_orphan_cleanup+0x665/0x740 [ext4]<br /> __ext4_fill_super+0x21ea/0x2b10 [ext4]<br /> ext4_fill_super+0x14d/0x360 [ext4]<br /> [...]<br /> =========================================================<br /> <br /> Normally interval is 0 until s_msg_ratelimit_state is initialized, so<br /> ___ratelimit() does nothing. But registering sysfs precedes initializing<br /> rs-&gt;lock, so it is possible to change rs-&gt;interval to a non-zero value<br /> via the msg_ratelimit_interval_ms interface of sysfs while rs-&gt;lock is<br /> uninitialized, and then a call to ext4_msg triggers the problem by<br /> accessing an uninitialized rs-&gt;lock. Therefore register sysfs after all<br /> initializations are complete to avoid such problems.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ena: Add validation for completion descriptors consistency<br /> <br /> Validate that `first` flag is set only for the first<br /> descriptor in multi-buffer packets.<br /> In case of an invalid descriptor, a reset will occur.<br /> A new reset reason for RX data corruption has been added.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block/ioctl: prefer different overflow check<br /> <br /> Running syzkaller with the newly reintroduced signed integer overflow<br /> sanitizer shows this report:<br /> <br /> [ 62.982337] ------------[ cut here ]------------<br /> [ 62.985692] cgroup: Invalid name<br /> [ 62.986211] UBSAN: signed-integer-overflow in ../block/ioctl.c:36:46<br /> [ 62.989370] 9pnet_fd: p9_fd_create_tcp (7343): problem connecting socket to 127.0.0.1<br /> [ 62.992992] 9223372036854775807 + 4095 cannot be represented in type &amp;#39;long long&amp;#39;<br /> [ 62.997827] 9pnet_fd: p9_fd_create_tcp (7345): problem connecting socket to 127.0.0.1<br /> [ 62.999369] random: crng reseeded on system resumption<br /> [ 63.000634] GUP no longer grows the stack in syz-executor.2 (7353): 20002000-20003000 (20001000)<br /> [ 63.000668] CPU: 0 PID: 7353 Comm: syz-executor.2 Not tainted 6.8.0-rc2-00035-gb3ef86b5a957 #1<br /> [ 63.000677] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 63.000682] Call Trace:<br /> [ 63.000686] <br /> [ 63.000731] dump_stack_lvl+0x93/0xd0<br /> [ 63.000919] __get_user_pages+0x903/0xd30<br /> [ 63.001030] __gup_longterm_locked+0x153e/0x1ba0<br /> [ 63.001041] ? _raw_read_unlock_irqrestore+0x17/0x50<br /> [ 63.001072] ? try_get_folio+0x29c/0x2d0<br /> [ 63.001083] internal_get_user_pages_fast+0x1119/0x1530<br /> [ 63.001109] iov_iter_extract_pages+0x23b/0x580<br /> [ 63.001206] bio_iov_iter_get_pages+0x4de/0x1220<br /> [ 63.001235] iomap_dio_bio_iter+0x9b6/0x1410<br /> [ 63.001297] __iomap_dio_rw+0xab4/0x1810<br /> [ 63.001316] iomap_dio_rw+0x45/0xa0<br /> [ 63.001328] ext4_file_write_iter+0xdde/0x1390<br /> [ 63.001372] vfs_write+0x599/0xbd0<br /> [ 63.001394] ksys_write+0xc8/0x190<br /> [ 63.001403] do_syscall_64+0xd4/0x1b0<br /> [ 63.001421] ? arch_exit_to_user_mode_prepare+0x3a/0x60<br /> [ 63.001479] entry_SYSCALL_64_after_hwframe+0x6f/0x77<br /> [ 63.001535] RIP: 0033:0x7f7fd3ebf539<br /> [ 63.001551] Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 14 00 00 90 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 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48<br /> [ 63.001562] RSP: 002b:00007f7fd32570c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> [ 63.001584] RAX: ffffffffffffffda RBX: 00007f7fd3ff3f80 RCX: 00007f7fd3ebf539<br /> [ 63.001590] RDX: 4db6d1e4f7e43360 RSI: 0000000020000000 RDI: 0000000000000004<br /> [ 63.001595] RBP: 00007f7fd3f1e496 R08: 0000000000000000 R09: 0000000000000000<br /> [ 63.001599] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> [ 63.001604] R13: 0000000000000006 R14: 00007f7fd3ff3f80 R15: 00007ffd415ad2b8<br /> ...<br /> [ 63.018142] ---[ end trace ]---<br /> <br /> Historically, the signed integer overflow sanitizer did not work in the<br /> kernel due to its interaction with `-fwrapv` but this has since been<br /> changed [1] in the newest version of Clang; It was re-enabled in the<br /> kernel with Commit 557f8c582a9ba8ab ("ubsan: Reintroduce signed overflow<br /> sanitizer").<br /> <br /> Let&amp;#39;s rework this overflow checking logic to not actually perform an<br /> overflow during the check itself, thus avoiding the UBSAN splat.<br /> <br /> [1]: https://github.com/llvm/llvm-project/pull/82432

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix UBSAN warning in kv_dpm.c<br /> <br /> Adds bounds check for sumo_vid_mapping_entry.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/radeon: fix UBSAN warning in kv_dpm.c<br /> <br /> Adds bounds check for sumo_vid_mapping_entry.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Disassociate vcpus from redistributor region on teardown<br /> <br /> When tearing down a redistributor region, make sure we don&amp;#39;t have<br /> any dangling pointer to that region stored in a vcpu.