Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: soc-pcm: don&amp;#39;t use soc_pcm_ret() on .prepare callback<br /> <br /> commit 1f5664351410 ("ASoC: lower "no backend DAIs enabled for ... Port"<br /> log severity") ignores -EINVAL error message on common soc_pcm_ret().<br /> It is used from many functions, ignoring -EINVAL is over-kill.<br /> <br /> The reason why -EINVAL was ignored was it really should only be used<br /> upon invalid parameters coming from userspace and in that case we don&amp;#39;t<br /> want to log an error since we do not want to give userspace a way to do<br /> a denial-of-service attack on the syslog / diskspace.<br /> <br /> So don&amp;#39;t use soc_pcm_ret() on .prepare callback is better idea.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: qcom: gcc-sm6350: Add missing parent_map for two clocks<br /> <br /> If a clk_rcg2 has a parent, it should also have parent_map defined,<br /> otherwise we&amp;#39;ll get a NULL pointer dereference when calling clk_set_rate<br /> like the following:<br /> <br /> [ 3.388105] Call trace:<br /> [ 3.390664] qcom_find_src_index+0x3c/0x70 (P)<br /> [ 3.395301] qcom_find_src_index+0x1c/0x70 (L)<br /> [ 3.399934] _freq_tbl_determine_rate+0x48/0x100<br /> [ 3.404753] clk_rcg2_determine_rate+0x1c/0x28<br /> [ 3.409387] clk_core_determine_round_nolock+0x58/0xe4<br /> [ 3.421414] clk_core_round_rate_nolock+0x48/0xfc<br /> [ 3.432974] clk_core_round_rate_nolock+0xd0/0xfc<br /> [ 3.444483] clk_core_set_rate_nolock+0x8c/0x300<br /> [ 3.455886] clk_set_rate+0x38/0x14c<br /> <br /> Add the parent_map property for two clocks where it&amp;#39;s missing and also<br /> un-inline the parent_data as well to keep the matching parent_map and<br /> parent_data together.

IBM Concert Software 1.0.5 uses an inadequate account lockout setting that could allow a remote attacker to brute force account credentials.

A deserialization of untrusted data vulnerability exists in NI G Web Development Software that may result in arbitrary code execution.  Successful exploitation requires an attacker to get a user to open a specially crafted project file.  This vulnerability affects G Web Development Software 2022 Q3 and prior versions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: don&amp;#39;t flush non-uploaded STAs<br /> <br /> If STA state is pre-moved to AUTHORIZED (such as in IBSS<br /> scenarios) and insertion fails, the station is freed.<br /> In this case, the driver never knew about the station,<br /> so trying to flush it is unexpected and may crash.<br /> <br /> Check if the sta was uploaded to the driver before and<br /> fix this.

A vulnerability classified as critical has been found in ChestnutCMS up to 1.5.2. This affects the function uploadFile of the file /dev-api/cms/file/upload. The manipulation of the argument file leads to unrestricted upload. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Cancel the running bpf_timer through kworker for PREEMPT_RT<br /> <br /> During the update procedure, when overwrite element in a pre-allocated<br /> htab, the freeing of old_element is protected by the bucket lock. The<br /> reason why the bucket lock is necessary is that the old_element has<br /> already been stashed in htab-&gt;extra_elems after alloc_htab_elem()<br /> returns. If freeing the old_element after the bucket lock is unlocked,<br /> the stashed element may be reused by concurrent update procedure and the<br /> freeing of old_element will run concurrently with the reuse of the<br /> old_element. However, the invocation of check_and_free_fields() may<br /> acquire a spin-lock which violates the lockdep rule because its caller<br /> has already held a raw-spin-lock (bucket lock). The following warning<br /> will be reported when such race happens:<br /> <br /> BUG: scheduling while atomic: test_progs/676/0x00000003<br /> 3 locks held by test_progs/676:<br /> #0: ffffffff864b0240 (rcu_read_lock_trace){....}-{0:0}, at: bpf_prog_test_run_syscall+0x2c0/0x830<br /> #1: ffff88810e961188 (&amp;htab-&gt;lockdep_key){....}-{2:2}, at: htab_map_update_elem+0x306/0x1500<br /> #2: ffff8881f4eac1b8 (&amp;base-&gt;softirq_expiry_lock){....}-{2:2}, at: hrtimer_cancel_wait_running+0xe9/0x1b0<br /> Modules linked in: bpf_testmod(O)<br /> Preemption disabled at:<br /> [] htab_map_update_elem+0x293/0x1500<br /> CPU: 0 UID: 0 PID: 676 Comm: test_progs Tainted: G ... 6.12.0+ #11<br /> Tainted: [W]=WARN, [O]=OOT_MODULE<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)...<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x57/0x70<br /> dump_stack+0x10/0x20<br /> __schedule_bug+0x120/0x170<br /> __schedule+0x300c/0x4800<br /> schedule_rtlock+0x37/0x60<br /> rtlock_slowlock_locked+0x6d9/0x54c0<br /> rt_spin_lock+0x168/0x230<br /> hrtimer_cancel_wait_running+0xe9/0x1b0<br /> hrtimer_cancel+0x24/0x30<br /> bpf_timer_delete_work+0x1d/0x40<br /> bpf_timer_cancel_and_free+0x5e/0x80<br /> bpf_obj_free_fields+0x262/0x4a0<br /> check_and_free_fields+0x1d0/0x280<br /> htab_map_update_elem+0x7fc/0x1500<br /> bpf_prog_9f90bc20768e0cb9_overwrite_cb+0x3f/0x43<br /> bpf_prog_ea601c4649694dbd_overwrite_timer+0x5d/0x7e<br /> bpf_prog_test_run_syscall+0x322/0x830<br /> __sys_bpf+0x135d/0x3ca0<br /> __x64_sys_bpf+0x75/0xb0<br /> x64_sys_call+0x1b5/0xa10<br /> do_syscall_64+0x3b/0xc0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> ...<br /> <br /> <br /> It seems feasible to break the reuse and refill of per-cpu extra_elems<br /> into two independent parts: reuse the per-cpu extra_elems with bucket<br /> lock being held and refill the old_element as per-cpu extra_elems after<br /> the bucket lock is unlocked. However, it will make the concurrent<br /> overwrite procedures on the same CPU return unexpected -E2BIG error when<br /> the map is full.<br /> <br /> Therefore, the patch fixes the lock problem by breaking the cancelling<br /> of bpf_timer into two steps for PREEMPT_RT:<br /> 1) use hrtimer_try_to_cancel() and check its return value<br /> 2) if the timer is running, use hrtimer_cancel() through a kworker to<br /> cancel it again<br /> Considering that the current implementation of hrtimer_cancel() will try<br /> to acquire a being held softirq_expiry_lock when the current timer is<br /> running, these steps above are reasonable. However, it also has<br /> downside. When the timer is running, the cancelling of the timer is<br /> delayed when releasing the last map uref. The delay is also fixable<br /> (e.g., break the cancelling of bpf timer into two parts: one part in<br /> locked scope, another one in unlocked scope), it can be revised later if<br /> necessary.<br /> <br /> It is a bit hard to decide the right fix tag. One reason is that the<br /> problem depends on PREEMPT_RT which is enabled in v6.12. Considering the<br /> softirq_expiry_lock lock exists since v5.4 and bpf_timer is introduced<br /> in v5.15, the bpf_timer commit is used in the fixes tag and an extra<br /> depends-on tag is added to state the dependency on PREEMPT_RT.<br /> <br /> Depends-on: v6.12+ with PREEMPT_RT enabled

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: reject mismatching sum of field_len with set key length<br /> <br /> The field length description provides the length of each separated key<br /> field in the concatenation, each field gets rounded up to 32-bits to<br /> calculate the pipapo rule width from pipapo_init(). The set key length<br /> provides the total size of the key aligned to 32-bits.<br /> <br /> Register-based arithmetics still allows for combining mismatching set<br /> key length and field length description, eg. set key length 10 and field<br /> description [ 5, 4 ] leading to pipapo width of 12.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: tegra - do not transfer req when tegra init fails<br /> <br /> The tegra_cmac_init or tegra_sha_init function may return an error when<br /> memory is exhausted. It should not transfer the request when they return<br /> an error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()<br /> <br /> The documentation for usb_driver_claim_interface() says that "the<br /> device lock" is needed when the function is called from places other<br /> than probe(). This appears to be the lock for the USB interface<br /> device. The Mediatek btusb code gets called via this path:<br /> <br /> Workqueue: hci0 hci_power_on [bluetooth]<br /> Call trace:<br /> usb_driver_claim_interface<br /> btusb_mtk_claim_iso_intf<br /> btusb_mtk_setup<br /> hci_dev_open_sync<br /> hci_power_on<br /> process_scheduled_works<br /> worker_thread<br /> kthread<br /> <br /> With the above call trace the device lock hasn&amp;#39;t been claimed. Claim<br /> it.<br /> <br /> Without this fix, we&amp;#39;d sometimes see the error "Failed to claim iso<br /> interface". Sometimes we&amp;#39;d even see worse errors, like a NULL pointer<br /> dereference (where `intf-&gt;dev.driver` was NULL) with a trace like:<br /> <br /> Call trace:<br /> usb_suspend_both<br /> usb_runtime_suspend<br /> __rpm_callback<br /> rpm_suspend<br /> pm_runtime_work<br /> process_scheduled_works<br /> <br /> Both errors appear to be fixed with the proper locking.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: bpf_local_storage: Always use bpf_mem_alloc in PREEMPT_RT<br /> <br /> In PREEMPT_RT, kmalloc(GFP_ATOMIC) is still not safe in non preemptible<br /> context. bpf_mem_alloc must be used in PREEMPT_RT. This patch is<br /> to enforce bpf_mem_alloc in the bpf_local_storage when CONFIG_PREEMPT_RT<br /> is enabled.<br /> <br /> [ 35.118559] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48<br /> [ 35.118566] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1832, name: test_progs<br /> [ 35.118569] preempt_count: 1, expected: 0<br /> [ 35.118571] RCU nest depth: 1, expected: 1<br /> [ 35.118577] INFO: lockdep is turned off.<br /> ...<br /> [ 35.118647] __might_resched+0x433/0x5b0<br /> [ 35.118677] rt_spin_lock+0xc3/0x290<br /> [ 35.118700] ___slab_alloc+0x72/0xc40<br /> [ 35.118723] __kmalloc_noprof+0x13f/0x4e0<br /> [ 35.118732] bpf_map_kzalloc+0xe5/0x220<br /> [ 35.118740] bpf_selem_alloc+0x1d2/0x7b0<br /> [ 35.118755] bpf_local_storage_update+0x2fa/0x8b0<br /> [ 35.118784] bpf_sk_storage_get_tracing+0x15a/0x1d0<br /> [ 35.118791] bpf_prog_9a118d86fca78ebb_trace_inet_sock_set_state+0x44/0x66<br /> [ 35.118795] bpf_trace_run3+0x222/0x400<br /> [ 35.118820] __bpf_trace_inet_sock_set_state+0x11/0x20<br /> [ 35.118824] trace_inet_sock_set_state+0x112/0x130<br /> [ 35.118830] inet_sk_state_store+0x41/0x90<br /> [ 35.118836] tcp_set_state+0x3b3/0x640<br /> <br /> There is no need to adjust the gfp_flags passing to the<br /> bpf_mem_cache_alloc_flags() which only honors the GFP_KERNEL.<br /> The verifier has ensured GFP_KERNEL is passed only in sleepable context.<br /> <br /> It has been an old issue since the first introduction of the<br /> bpf_local_storage ~5 years ago, so this patch targets the bpf-next.<br /> <br /> bpf_mem_alloc is needed to solve it, so the Fixes tag is set<br /> to the commit when bpf_mem_alloc was first used in the bpf_local_storage.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> team: prevent adding a device which is already a team device lower<br /> <br /> Prevent adding a device which is already a team device lower,<br /> e.g. adding veth0 if vlan1 was already added and veth0 is a lower of<br /> vlan1.<br /> <br /> This is not useful in practice and can lead to recursive locking:<br /> <br /> $ ip link add veth0 type veth peer name veth1<br /> $ ip link set veth0 up<br /> $ ip link set veth1 up<br /> $ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1<br /> $ ip link add team0 type team<br /> $ ip link set veth0.1 down<br /> $ ip link set veth0.1 master team0<br /> team0: Port device veth0.1 added<br /> $ ip link set veth0 down<br /> $ ip link set veth0 master team0<br /> <br /> ============================================<br /> WARNING: possible recursive locking detected<br /> 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted<br /> --------------------------------------------<br /> ip/7684 is trying to acquire lock:<br /> ffff888016848e00 (team-&gt;team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)<br /> <br /> but task is already holding lock:<br /> ffff888016848e00 (team-&gt;team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977)<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(team-&gt;team_lock_key);<br /> lock(team-&gt;team_lock_key);<br /> <br /> *** DEADLOCK ***<br /> <br /> May be due to missing lock nesting notation<br /> <br /> 2 locks held by ip/7684:<br /> <br /> stack backtrace:<br /> CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:122)<br /> print_deadlock_bug.cold (kernel/locking/lockdep.c:3040)<br /> __lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226)<br /> ? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548)<br /> lock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851)<br /> ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)<br /> ? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2))<br /> ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)<br /> ? lock_acquire (kernel/locking/lockdep.c:5822)<br /> ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)<br /> __mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735)<br /> ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)<br /> ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)<br /> ? fib_sync_up (net/ipv4/fib_semantics.c:2167)<br /> ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)<br /> team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)<br /> notifier_call_chain (kernel/notifier.c:85)<br /> call_netdevice_notifiers_info (net/core/dev.c:1996)<br /> __dev_notify_flags (net/core/dev.c:8993)<br /> ? __dev_change_flags (net/core/dev.c:8975)<br /> dev_change_flags (net/core/dev.c:9027)<br /> vlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470)<br /> ? br_device_event (net/bridge/br.c:143)<br /> notifier_call_chain (kernel/notifier.c:85)<br /> call_netdevice_notifiers_info (net/core/dev.c:1996)<br /> dev_open (net/core/dev.c:1519 net/core/dev.c:1505)<br /> team_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977)<br /> ? __pfx_team_add_slave (drivers/net/team/team_core.c:1972)<br /> do_set_master (net/core/rtnetlink.c:2917)<br /> do_setlink.isra.0 (net/core/rtnetlink.c:3117)