Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Check valid rport returned by fc_bsg_to_rport()<br /> <br /> Klocwork reported warning of rport maybe NULL and will be dereferenced.<br /> rport returned by call to fc_bsg_to_rport() could be NULL and dereferenced.<br /> <br /> Check valid rport returned by fc_bsg_to_rport().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Devcom, fix error flow in mlx5_devcom_register_device<br /> <br /> In case devcom allocation is failed, mlx5 is always freeing the priv.<br /> However, this priv might have been allocated by a different thread,<br /> and freeing it might lead to use-after-free bugs.<br /> Fix it by freeing the priv only in case it was allocated by the<br /> running thread.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: Fix memory leak in rx_desc and tx_desc<br /> <br /> Currently when ath12k_dp_cc_desc_init() is called we allocate<br /> memory to rx_descs and tx_descs. In ath12k_dp_cc_cleanup(), during<br /> descriptor cleanup rx_descs and tx_descs memory is not freed.<br /> <br /> This is cause of memory leak. These allocated memory should be<br /> freed in ath12k_dp_cc_cleanup.<br /> <br /> In ath12k_dp_cc_desc_init(), we can save base address of rx_descs<br /> and tx_descs. In ath12k_dp_cc_cleanup(), we can free rx_descs and<br /> tx_descs memory using their base address.<br /> <br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/pseries: fix possible memory leak in ibmebus_bus_init()<br /> <br /> If device_register() returns error in ibmebus_bus_init(), name of kobject<br /> which is allocated in dev_set_name() called in device_add() is leaked.<br /> <br /> As comment of device_add() says, it should call put_device() to drop<br /> the reference count that was set in device_initialize() when it fails,<br /> so the name can be freed in kobject_cleanup().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/hdmi: Add missing check for alloc_ordered_workqueue<br /> <br /> Add check for the return value of alloc_ordered_workqueue as it may return<br /> NULL pointer and cause NULL pointer dereference in `hdmi_hdcp.c` and<br /> `hdmi_hpd.c`.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/517211/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix stack overflow when LRO is disabled for virtual interfaces<br /> <br /> When the virtual interface&amp;#39;s feature is updated, it synchronizes the<br /> updated feature for its own lower interface.<br /> This propagation logic should be worked as the iteration, not recursively.<br /> But it works recursively due to the netdev notification unexpectedly.<br /> This problem occurs when it disables LRO only for the team and bonding<br /> interface type.<br /> <br /> team0<br /> |<br /> +------+------+-----+-----+<br /> | | | | |<br /> team1 team2 team3 ... team200<br /> <br /> If team0&amp;#39;s LRO feature is updated, it generates the NETDEV_FEAT_CHANGE<br /> event to its own lower interfaces(team1 ~ team200).<br /> It is worked by netdev_sync_lower_features().<br /> So, the NETDEV_FEAT_CHANGE notification logic of each lower interface<br /> work iteratively.<br /> But generated NETDEV_FEAT_CHANGE event is also sent to the upper<br /> interface too.<br /> upper interface(team0) generates the NETDEV_FEAT_CHANGE event for its own<br /> lower interfaces again.<br /> lower and upper interfaces receive this event and generate this<br /> event again and again.<br /> So, the stack overflow occurs.<br /> <br /> But it is not the infinite loop issue.<br /> Because the netdev_sync_lower_features() updates features before<br /> generating the NETDEV_FEAT_CHANGE event.<br /> Already synchronized lower interfaces skip notification logic.<br /> So, it is just the problem that iteration logic is changed to the<br /> recursive unexpectedly due to the notification mechanism.<br /> <br /> Reproducer:<br /> <br /> ip link add team0 type team<br /> ethtool -K team0 lro on<br /> for i in {1..200}<br /> do<br /> ip link add team$i master team0 type team<br /> ethtool -K team$i lro on<br /> done<br /> <br /> ethtool -K team0 lro off<br /> <br /> In order to fix it, the notifier_ctx member of bonding/team is introduced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/psi: use kernfs polling functions for PSI trigger polling<br /> <br /> Destroying psi trigger in cgroup_file_release causes UAF issues when<br /> a cgroup is removed from under a polling process. This is happening<br /> because cgroup removal causes a call to cgroup_file_release while the<br /> actual file is still alive. Destroying the trigger at this point would<br /> also destroy its waitqueue head and if there is still a polling process<br /> on that file accessing the waitqueue, it will step on the freed pointer:<br /> <br /> do_select<br /> vfs_poll<br /> do_rmdir<br /> cgroup_rmdir<br /> kernfs_drain_open_files<br /> cgroup_file_release<br /> cgroup_pressure_release<br /> psi_trigger_destroy<br /> wake_up_pollfree(&amp;t-&gt;event_wait)<br /> // vfs_poll is unblocked<br /> synchronize_rcu<br /> kfree(t)<br /> poll_freewait -&gt; UAF access to the trigger&amp;#39;s waitqueue head<br /> <br /> Patch [1] fixed this issue for epoll() case using wake_up_pollfree(),<br /> however the same issue exists for synchronous poll() case.<br /> The root cause of this issue is that the lifecycles of the psi trigger&amp;#39;s<br /> waitqueue and of the file associated with the trigger are different. Fix<br /> this by using kernfs_generic_poll function when polling on cgroup-specific<br /> psi triggers. It internally uses kernfs_open_node-&gt;poll waitqueue head<br /> with its lifecycle tied to the file&amp;#39;s lifecycle. This also renders the<br /> fix in [1] obsolete, so revert it.<br /> <br /> [1] commit c2dbe32d5db5 ("sched/psi: Fix use-after-free in ep_remove_wait_queue()")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: r8712: Fix memory leak in _r8712_init_xmit_priv()<br /> <br /> In the above mentioned routine, memory is allocated in several places.<br /> If the first succeeds and a later one fails, the routine will leak memory.<br /> This patch fixes commit 2865d42c78a9 ("staging: r8712u: Add the new driver<br /> to the mainline kernel"). A potential memory leak in<br /> r8712_xmit_resource_alloc() is also addressed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix assertion of exclop condition when starting balance<br /> <br /> Balance as exclusive state is compatible with paused balance and device<br /> add, which makes some things more complicated. The assertion of valid<br /> states when starting from paused balance needs to take into account two<br /> more states, the combinations can be hit when there are several threads<br /> racing to start balance and device add. This won&amp;#39;t typically happen when<br /> the commands are started from command line.<br /> <br /> Scenario 1: With exclusive_operation state == BTRFS_EXCLOP_NONE.<br /> <br /> Concurrently adding multiple devices to the same mount point and<br /> btrfs_exclop_finish executed finishes before assertion in<br /> btrfs_exclop_balance, exclusive_operation will changed to<br /> BTRFS_EXCLOP_NONE state which lead to assertion failed:<br /> <br /> fs_info-&gt;exclusive_operation == BTRFS_EXCLOP_BALANCE ||<br /> fs_info-&gt;exclusive_operation == BTRFS_EXCLOP_DEV_ADD,<br /> in fs/btrfs/ioctl.c:456<br /> Call Trace:<br /> <br /> btrfs_exclop_balance+0x13c/0x310<br /> ? memdup_user+0xab/0xc0<br /> ? PTR_ERR+0x17/0x20<br /> btrfs_ioctl_add_dev+0x2ee/0x320<br /> btrfs_ioctl+0x9d5/0x10d0<br /> ? btrfs_ioctl_encoded_write+0xb80/0xb80<br /> __x64_sys_ioctl+0x197/0x210<br /> do_syscall_64+0x3c/0xb0<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Scenario 2: With exclusive_operation state == BTRFS_EXCLOP_BALANCE_PAUSED.<br /> <br /> Concurrently adding multiple devices to the same mount point and<br /> btrfs_exclop_balance executed finish before the latter thread execute<br /> assertion in btrfs_exclop_balance, exclusive_operation will changed to<br /> BTRFS_EXCLOP_BALANCE_PAUSED state which lead to assertion failed:<br /> <br /> fs_info-&gt;exclusive_operation == BTRFS_EXCLOP_BALANCE ||<br /> fs_info-&gt;exclusive_operation == BTRFS_EXCLOP_DEV_ADD ||<br /> fs_info-&gt;exclusive_operation == BTRFS_EXCLOP_NONE,<br /> fs/btrfs/ioctl.c:458<br /> Call Trace:<br /> <br /> btrfs_exclop_balance+0x240/0x410<br /> ? memdup_user+0xab/0xc0<br /> ? PTR_ERR+0x17/0x20<br /> btrfs_ioctl_add_dev+0x2ee/0x320<br /> btrfs_ioctl+0x9d5/0x10d0<br /> ? btrfs_ioctl_encoded_write+0xb80/0xb80<br /> __x64_sys_ioctl+0x197/0x210<br /> do_syscall_64+0x3c/0xb0<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> An example of the failed assertion is below, which shows that the<br /> paused balance is also needed to be checked.<br /> <br /> root@syzkaller:/home/xsk# ./repro<br /> Failed to add device /dev/vda, errno 14<br /> Failed to add device /dev/vda, errno 14<br /> Failed to add device /dev/vda, errno 14<br /> Failed to add device /dev/vda, errno 14<br /> Failed to add device /dev/vda, errno 14<br /> Failed to add device /dev/vda, errno 14<br /> Failed to add device /dev/vda, errno 14<br /> Failed to add device /dev/vda, errno 14<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.611428][ T7970] BTRFS info (device loop0): fs_info exclusive_operation: 0<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.613973][ T7971] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.615456][ T7972] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.617528][ T7973] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.618359][ T7974] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.622589][ T7975] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.624034][ T7976] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.626420][ T7977] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.627643][ T7978] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.629006][ T7979] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> [ 416.630298][ T7980] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> Fai<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/core: Fix GID entry ref leak when create_ah fails<br /> <br /> If AH create request fails, release sgid_attr to avoid GID entry<br /> referrence leak reported while releasing GID table

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binder: fix memory leak in binder_init()<br /> <br /> In binder_init(), the destruction of binder_alloc_shrinker_init() is not<br /> performed in the wrong path, which will cause memory leaks. So this commit<br /> introduces binder_alloc_shrinker_exit() and calls it in the wrong path to<br /> fix that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Fix data-race around unix_tot_inflight.<br /> <br /> unix_tot_inflight is changed under spin_lock(unix_gc_lock), but<br /> unix_release_sock() reads it locklessly.<br /> <br /> Let&amp;#39;s use READ_ONCE() for unix_tot_inflight.<br /> <br /> Note that the writer side was marked by commit 9d6d7f1cb67c ("af_unix:<br /> annote lockless accesses to unix_tot_inflight &amp; gc_in_progress")<br /> <br /> BUG: KCSAN: data-race in unix_inflight / unix_release_sock<br /> <br /> write (marked) to 0xffffffff871852b8 of 4 bytes by task 123 on cpu 1:<br /> unix_inflight+0x130/0x180 net/unix/scm.c:64<br /> unix_attach_fds+0x137/0x1b0 net/unix/scm.c:123<br /> unix_scm_to_skb net/unix/af_unix.c:1832 [inline]<br /> unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1955<br /> sock_sendmsg_nosec net/socket.c:724 [inline]<br /> sock_sendmsg+0x148/0x160 net/socket.c:747<br /> ____sys_sendmsg+0x4e4/0x610 net/socket.c:2493<br /> ___sys_sendmsg+0xc6/0x140 net/socket.c:2547<br /> __sys_sendmsg+0x94/0x140 net/socket.c:2576<br /> __do_sys_sendmsg net/socket.c:2585 [inline]<br /> __se_sys_sendmsg net/socket.c:2583 [inline]<br /> __x64_sys_sendmsg+0x45/0x50 net/socket.c:2583<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> read to 0xffffffff871852b8 of 4 bytes by task 4891 on cpu 0:<br /> unix_release_sock+0x608/0x910 net/unix/af_unix.c:671<br /> unix_release+0x59/0x80 net/unix/af_unix.c:1058<br /> __sock_release+0x7d/0x170 net/socket.c:653<br /> sock_close+0x19/0x30 net/socket.c:1385<br /> __fput+0x179/0x5e0 fs/file_table.c:321<br /> ____fput+0x15/0x20 fs/file_table.c:349<br /> task_work_run+0x116/0x1a0 kernel/task_work.c:179<br /> resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]<br /> exit_to_user_mode_loop kernel/entry/common.c:171 [inline]<br /> exit_to_user_mode_prepare+0x174/0x180 kernel/entry/common.c:204<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline]<br /> syscall_exit_to_user_mode+0x1a/0x30 kernel/entry/common.c:297<br /> do_syscall_64+0x4b/0x90 arch/x86/entry/common.c:86<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> value changed: 0x00000000 -&gt; 0x00000001<br /> <br /> Reported by Kernel Concurrency Sanitizer on:<br /> CPU: 0 PID: 4891 Comm: systemd-coredum Not tainted 6.4.0-rc5-01219-gfa0e21fa4443 #5<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014