Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cfi: Fix __cfi_slowpath_diag RCU usage with cpuidle<br /> <br /> RCU_NONIDLE usage during __cfi_slowpath_diag can result in an invalid<br /> RCU state in the cpuidle code path:<br /> <br /> WARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:613 rcu_eqs_enter+0xe4/0x138<br /> ...<br /> Call trace:<br /> rcu_eqs_enter+0xe4/0x138<br /> rcu_idle_enter+0xa8/0x100<br /> cpuidle_enter_state+0x154/0x3a8<br /> cpuidle_enter+0x3c/0x58<br /> do_idle.llvm.6590768638138871020+0x1f4/0x2ec<br /> cpu_startup_entry+0x28/0x2c<br /> secondary_start_kernel+0x1b8/0x220<br /> __secondary_switched+0x94/0x98<br /> <br /> Instead, call rcu_irq_enter/exit to wake up RCU only when needed and<br /> disable interrupts for the entire CFI shadow/module check when we do.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm mirror log: round up region bitmap size to BITS_PER_LONG<br /> <br /> The code in dm-log rounds up bitset_size to 32 bits. It then uses<br /> find_next_zero_bit_le on the allocated region. find_next_zero_bit_le<br /> accesses the bitmap using unsigned long pointers. So, on 64-bit<br /> architectures, it may access 4 bytes beyond the allocated size.<br /> <br /> Fix this bug by rounding up bitset_size to BITS_PER_LONG.<br /> <br /> This bug was found by running the lvm2 testsuite with kasan.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: lpc32xx_udc: Fix refcount leak in lpc32xx_udc_probe<br /> <br /> of_parse_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.<br /> of_node_put() will check NULL pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bus: fsl-mc-bus: fix KASAN use-after-free in fsl_mc_bus_remove()<br /> <br /> In fsl_mc_bus_remove(), mc-&gt;root_mc_bus_dev-&gt;mc_io is passed to<br /> fsl_destroy_mc_io(). However, mc-&gt;root_mc_bus_dev is already freed in<br /> fsl_mc_device_remove(). Then reference to mc-&gt;root_mc_bus_dev-&gt;mc_io<br /> triggers KASAN use-after-free. To avoid the use-after-free, keep the<br /> reference to mc-&gt;root_mc_bus_dev-&gt;mc_io in a local variable and pass to<br /> fsl_destroy_mc_io().<br /> <br /> This patch needs rework to apply to kernels older than v5.15.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix hang during unmount when block group reclaim task is running<br /> <br /> When we start an unmount, at close_ctree(), if we have the reclaim task<br /> running and in the middle of a data block group relocation, we can trigger<br /> a deadlock when stopping an async reclaim task, producing a trace like the<br /> following:<br /> <br /> [629724.498185] task:kworker/u16:7 state:D stack: 0 pid:681170 ppid: 2 flags:0x00004000<br /> [629724.499760] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs]<br /> [629724.501267] Call Trace:<br /> [629724.501759] <br /> [629724.502174] __schedule+0x3cb/0xed0<br /> [629724.502842] schedule+0x4e/0xb0<br /> [629724.503447] btrfs_wait_on_delayed_iputs+0x7c/0xc0 [btrfs]<br /> [629724.504534] ? prepare_to_wait_exclusive+0xc0/0xc0<br /> [629724.505442] flush_space+0x423/0x630 [btrfs]<br /> [629724.506296] ? rcu_read_unlock_trace_special+0x20/0x50<br /> [629724.507259] ? lock_release+0x220/0x4a0<br /> [629724.507932] ? btrfs_get_alloc_profile+0xb3/0x290 [btrfs]<br /> [629724.508940] ? do_raw_spin_unlock+0x4b/0xa0<br /> [629724.509688] btrfs_async_reclaim_metadata_space+0x139/0x320 [btrfs]<br /> [629724.510922] process_one_work+0x252/0x5a0<br /> [629724.511694] ? process_one_work+0x5a0/0x5a0<br /> [629724.512508] worker_thread+0x52/0x3b0<br /> [629724.513220] ? process_one_work+0x5a0/0x5a0<br /> [629724.514021] kthread+0xf2/0x120<br /> [629724.514627] ? kthread_complete_and_exit+0x20/0x20<br /> [629724.515526] ret_from_fork+0x22/0x30<br /> [629724.516236] <br /> [629724.516694] task:umount state:D stack: 0 pid:719055 ppid:695412 flags:0x00004000<br /> [629724.518269] Call Trace:<br /> [629724.518746] <br /> [629724.519160] __schedule+0x3cb/0xed0<br /> [629724.519835] schedule+0x4e/0xb0<br /> [629724.520467] schedule_timeout+0xed/0x130<br /> [629724.521221] ? lock_release+0x220/0x4a0<br /> [629724.521946] ? lock_acquired+0x19c/0x420<br /> [629724.522662] ? trace_hardirqs_on+0x1b/0xe0<br /> [629724.523411] __wait_for_common+0xaf/0x1f0<br /> [629724.524189] ? usleep_range_state+0xb0/0xb0<br /> [629724.524997] __flush_work+0x26d/0x530<br /> [629724.525698] ? flush_workqueue_prep_pwqs+0x140/0x140<br /> [629724.526580] ? lock_acquire+0x1a0/0x310<br /> [629724.527324] __cancel_work_timer+0x137/0x1c0<br /> [629724.528190] close_ctree+0xfd/0x531 [btrfs]<br /> [629724.529000] ? evict_inodes+0x166/0x1c0<br /> [629724.529510] generic_shutdown_super+0x74/0x120<br /> [629724.530103] kill_anon_super+0x14/0x30<br /> [629724.530611] btrfs_kill_super+0x12/0x20 [btrfs]<br /> [629724.531246] deactivate_locked_super+0x31/0xa0<br /> [629724.531817] cleanup_mnt+0x147/0x1c0<br /> [629724.532319] task_work_run+0x5c/0xa0<br /> [629724.532984] exit_to_user_mode_prepare+0x1a6/0x1b0<br /> [629724.533598] syscall_exit_to_user_mode+0x16/0x40<br /> [629724.534200] do_syscall_64+0x48/0x90<br /> [629724.534667] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [629724.535318] RIP: 0033:0x7fa2b90437a7<br /> [629724.535804] RSP: 002b:00007ffe0b7e4458 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6<br /> [629724.536912] RAX: 0000000000000000 RBX: 00007fa2b9182264 RCX: 00007fa2b90437a7<br /> [629724.538156] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000555d6cf20dd0<br /> [629724.539053] RBP: 0000555d6cf20ba0 R08: 0000000000000000 R09: 00007ffe0b7e3200<br /> [629724.539956] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> [629724.540883] R13: 0000555d6cf20dd0 R14: 0000555d6cf20cb0 R15: 0000000000000000<br /> [629724.541796] <br /> <br /> This happens because:<br /> <br /> 1) Before entering close_ctree() we have the async block group reclaim<br /> task running and relocating a data block group;<br /> <br /> 2) There&amp;#39;s an async metadata (or data) space reclaim task running;<br /> <br /> 3) We enter close_ctree() and park the cleaner kthread;<br /> <br /> 4) The async space reclaim task is at flush_space() and runs all the<br /> existing delayed iputs;<br /> <br /> 5) Before the async space reclaim task calls<br /> btrfs_wait_on_delayed_iputs(), the block group reclaim task which is<br /> doing the data block group relocation, creates a delayed iput at<br /> replace_file_extents() (called when COWing leaves that have file extent<br /> items pointing to relocated data exten<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ibmvfc: Store vhost pointer during subcrq allocation<br /> <br /> Currently the back pointer from a queue to the vhost adapter isn&amp;#39;t set<br /> until after subcrq interrupt registration. The value is available when a<br /> queue is first allocated and can/should be also set for primary and async<br /> queues as well as subcrqs.<br /> <br /> This fixes a crash observed during kexec/kdump on Power 9 with legacy XICS<br /> interrupt controller where a pending subcrq interrupt from the previous<br /> kernel can be replayed immediately upon IRQ registration resulting in<br /> dereference of a garbage backpointer in ibmvfc_interrupt_scsi().<br /> <br /> Kernel attempted to read user page (58) - exploit attempt? (uid: 0)<br /> BUG: Kernel NULL pointer dereference on read at 0x00000058<br /> Faulting instruction address: 0xc008000003216a08<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> ...<br /> NIP [c008000003216a08] ibmvfc_interrupt_scsi+0x40/0xb0 [ibmvfc]<br /> LR [c0000000082079e8] __handle_irq_event_percpu+0x98/0x270<br /> Call Trace:<br /> [c000000047fa3d80] [c0000000123e6180] 0xc0000000123e6180 (unreliable)<br /> [c000000047fa3df0] [c0000000082079e8] __handle_irq_event_percpu+0x98/0x270<br /> [c000000047fa3ea0] [c000000008207d18] handle_irq_event+0x98/0x188<br /> [c000000047fa3ef0] [c00000000820f564] handle_fasteoi_irq+0xc4/0x310<br /> [c000000047fa3f40] [c000000008205c60] generic_handle_irq+0x50/0x80<br /> [c000000047fa3f60] [c000000008015c40] __do_irq+0x70/0x1a0<br /> [c000000047fa3f90] [c000000008016d7c] __do_IRQ+0x9c/0x130<br /> [c000000014622f60] [0000000020000000] 0x20000000<br /> [c000000014622ff0] [c000000008016e50] do_IRQ+0x40/0xa0<br /> [c000000014623020] [c000000008017044] replay_soft_interrupts+0x194/0x2f0<br /> [c000000014623210] [c0000000080172a8] arch_local_irq_restore+0x108/0x170<br /> [c000000014623240] [c000000008eb1008] _raw_spin_unlock_irqrestore+0x58/0xb0<br /> [c000000014623270] [c00000000820b12c] __setup_irq+0x49c/0x9f0<br /> [c000000014623310] [c00000000820b7c0] request_threaded_irq+0x140/0x230<br /> [c000000014623380] [c008000003212a50] ibmvfc_register_scsi_channel+0x1e8/0x2f0 [ibmvfc]<br /> [c000000014623450] [c008000003213d1c] ibmvfc_init_sub_crqs+0xc4/0x1f0 [ibmvfc]<br /> [c0000000146234d0] [c0080000032145a8] ibmvfc_reset_crq+0x150/0x210 [ibmvfc]<br /> [c000000014623550] [c0080000032147c8] ibmvfc_init_crq+0x160/0x280 [ibmvfc]<br /> [c0000000146235f0] [c00800000321a9cc] ibmvfc_probe+0x2a4/0x530 [ibmvfc]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/mdp4: Fix refcount leak in mdp4_modeset_init_intf<br /> <br /> of_graph_get_remote_node() returns remote device node pointer with<br /> refcount incremented, we should use of_node_put() on it<br /> when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/488473/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: disable the elevator int del_gendisk<br /> <br /> The elevator is only used for file system requests, which are stopped in<br /> del_gendisk. Move disabling the elevator and freeing the scheduler tags<br /> to the end of del_gendisk instead of doing that work in disk_release and<br /> blk_cleanup_queue to avoid a use after free on q-&gt;tag_set from<br /> disk_release as the tag_set might not be alive at that point.<br /> <br /> Move the blk_qos_exit call as well, as it just depends on the elevator<br /> exit and would be the only reason to keep the not exactly cheap queue<br /> freeze in disk_release.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igb: fix a use-after-free issue in igb_clean_tx_ring<br /> <br /> Fix the following use-after-free bug in igb_clean_tx_ring routine when<br /> the NIC is running in XDP mode. The issue can be triggered redirecting<br /> traffic into the igb NIC and then closing the device while the traffic<br /> is flowing.<br /> <br /> [ 73.322719] CPU: 1 PID: 487 Comm: xdp_redirect Not tainted 5.18.3-apu2 #9<br /> [ 73.330639] Hardware name: PC Engines APU2/APU2, BIOS 4.0.7 02/28/2017<br /> [ 73.337434] RIP: 0010:refcount_warn_saturate+0xa7/0xf0<br /> [ 73.362283] RSP: 0018:ffffc9000081f798 EFLAGS: 00010282<br /> [ 73.367761] RAX: 0000000000000000 RBX: ffffc90000420f80 RCX: 0000000000000000<br /> [ 73.375200] RDX: ffff88811ad22d00 RSI: ffff88811ad171e0 RDI: ffff88811ad171e0<br /> [ 73.382590] RBP: 0000000000000900 R08: ffffffff82298f28 R09: 0000000000000058<br /> [ 73.390008] R10: 0000000000000219 R11: ffffffff82280f40 R12: 0000000000000090<br /> [ 73.397356] R13: ffff888102343a40 R14: ffff88810359e0e4 R15: 0000000000000000<br /> [ 73.404806] FS: 00007ff38d31d740(0000) GS:ffff88811ad00000(0000) knlGS:0000000000000000<br /> [ 73.413129] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 73.419096] CR2: 000055cff35f13f8 CR3: 0000000106391000 CR4: 00000000000406e0<br /> [ 73.426565] Call Trace:<br /> [ 73.429087] <br /> [ 73.431314] igb_clean_tx_ring+0x43/0x140 [igb]<br /> [ 73.436002] igb_down+0x1d7/0x220 [igb]<br /> [ 73.439974] __igb_close+0x3c/0x120 [igb]<br /> [ 73.444118] igb_xdp+0x10c/0x150 [igb]<br /> [ 73.447983] ? igb_pci_sriov_configure+0x70/0x70 [igb]<br /> [ 73.453362] dev_xdp_install+0xda/0x110<br /> [ 73.457371] dev_xdp_attach+0x1da/0x550<br /> [ 73.461369] do_setlink+0xfd0/0x10f0<br /> [ 73.465166] ? __nla_validate_parse+0x89/0xc70<br /> [ 73.469714] rtnl_setlink+0x11a/0x1e0<br /> [ 73.473547] rtnetlink_rcv_msg+0x145/0x3d0<br /> [ 73.477709] ? rtnl_calcit.isra.0+0x130/0x130<br /> [ 73.482258] netlink_rcv_skb+0x8d/0x110<br /> [ 73.486229] netlink_unicast+0x230/0x340<br /> [ 73.490317] netlink_sendmsg+0x215/0x470<br /> [ 73.494395] __sys_sendto+0x179/0x190<br /> [ 73.498268] ? move_addr_to_user+0x37/0x70<br /> [ 73.502547] ? __sys_getsockname+0x84/0xe0<br /> [ 73.506853] ? netlink_setsockopt+0x1c1/0x4a0<br /> [ 73.511349] ? __sys_setsockopt+0xc8/0x1d0<br /> [ 73.515636] __x64_sys_sendto+0x20/0x30<br /> [ 73.519603] do_syscall_64+0x3b/0x80<br /> [ 73.523399] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [ 73.528712] RIP: 0033:0x7ff38d41f20c<br /> [ 73.551866] RSP: 002b:00007fff3b945a68 EFLAGS: 00000246 ORIG_RAX: 000000000000002c<br /> [ 73.559640] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ff38d41f20c<br /> [ 73.567066] RDX: 0000000000000034 RSI: 00007fff3b945b30 RDI: 0000000000000003<br /> [ 73.574457] RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000<br /> [ 73.581852] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff3b945ab0<br /> [ 73.589179] R13: 0000000000000000 R14: 0000000000000003 R15: 00007fff3b945b30<br /> [ 73.596545] <br /> [ 73.598842] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix use-after-free Read in tipc_named_reinit<br /> <br /> syzbot found the following issue on:<br /> ==================================================================<br /> BUG: KASAN: use-after-free in tipc_named_reinit+0x94f/0x9b0<br /> net/tipc/name_distr.c:413<br /> Read of size 8 at addr ffff88805299a000 by task kworker/1:9/23764<br /> <br /> CPU: 1 PID: 23764 Comm: kworker/1:9 Not tainted<br /> 5.18.0-rc4-syzkaller-00878-g17d49e6e8012 #0<br /> Hardware name: Google Compute Engine/Google Compute Engine,<br /> BIOS Google 01/01/2011<br /> Workqueue: events tipc_net_finalize_work<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> print_address_description.constprop.0.cold+0xeb/0x495<br /> mm/kasan/report.c:313<br /> print_report mm/kasan/report.c:429 [inline]<br /> kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491<br /> tipc_named_reinit+0x94f/0x9b0 net/tipc/name_distr.c:413<br /> tipc_net_finalize+0x234/0x3d0 net/tipc/net.c:138<br /> process_one_work+0x996/0x1610 kernel/workqueue.c:2289<br /> worker_thread+0x665/0x1080 kernel/workqueue.c:2436<br /> kthread+0x2e9/0x3a0 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298<br /> <br /> [...]<br /> ==================================================================<br /> <br /> In the commit<br /> d966ddcc3821 ("tipc: fix a deadlock when flushing scheduled work"),<br /> the cancel_work_sync() function just to make sure ONLY the work<br /> tipc_net_finalize_work() is executing/pending on any CPU completed before<br /> tipc namespace is destroyed through tipc_exit_net(). But this function<br /> is not guaranteed the work is the last queued. So, the destroyed instance<br /> may be accessed in the work which will try to enqueue later.<br /> <br /> In order to completely fix, we re-order the calling of cancel_work_sync()<br /> to make sure the work tipc_net_finalize_work() was last queued and it<br /> must be completed by calling cancel_work_sync().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix request_sock leak in sk lookup helpers<br /> <br /> A customer reported a request_socket leak in a Calico cloud environment. We<br /> found that a BPF program was doing a socket lookup with takes a refcnt on<br /> the socket and that it was finding the request_socket but returning the parent<br /> LISTEN socket via sk_to_full_sk() without decrementing the child request socket<br /> 1st, resulting in request_sock slab object leak. This patch retains the<br /> existing behaviour of returning full socks to the caller but it also decrements<br /> the child request_socket if one is present before doing so to prevent the leak.<br /> <br /> Thanks to Curtis Taylor for all the help in diagnosing and testing this. And<br /> thanks to Antoine Tenart for the reproducer and patch input.<br /> <br /> v2 of this patch contains, refactor as per Daniel Borkmann&amp;#39;s suggestions to<br /> validate RCU flags on the listen socket so that it balances with bpf_sk_release()<br /> and update comments as per Martin KaFai Lau&amp;#39;s suggestion. One small change to<br /> Daniels suggestion, put "sk = sk2" under "if (sk2 != sk)" to avoid an extra<br /> instruction.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: use get_random_u32 instead of prandom<br /> <br /> bh might occur while updating per-cpu rnd_state from user context,<br /> ie. local_out path.<br /> <br /> BUG: using smp_processor_id() in preemptible [00000000] code: nginx/2725<br /> caller is nft_ng_random_eval+0x24/0x54 [nft_numgen]<br /> Call Trace:<br /> check_preemption_disabled+0xde/0xe0<br /> nft_ng_random_eval+0x24/0x54 [nft_numgen]<br /> <br /> Use the random driver instead, this also avoids need for local prandom<br /> state. Moreover, prandom now uses the random driver since d4150779e60f<br /> ("random32: use real rng for non-deterministic randomness").<br /> <br /> Based on earlier patch from Pablo Neira.