Vulnerabilities

ServiceNow has addressed an authorization bypass vulnerability that was identified in the Washington release of the Now Platform. This vulnerability, if exploited, potentially could enable an authenticated user to access unauthorized data stored within the Now Platform that the user otherwise would not be entitled to access. <br /> <br /> This issue is addressed in the listed patches and family release, which have been made available to hosted and self-hosted customers, as well as partners.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: nuvoton: Fix an error check in npcm_video_ece_init()<br /> <br /> When function of_find_device_by_node() fails, it returns NULL instead of<br /> an error code. So the corresponding error check logic should be modified<br /> to check whether the return value is NULL and set the error code to be<br /> returned as -ENODEV.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: misc_minor_alloc to use ida for all dynamic/misc dynamic minors<br /> <br /> misc_minor_alloc was allocating id using ida for minor only in case of<br /> MISC_DYNAMIC_MINOR but misc_minor_free was always freeing ids<br /> using ida_free causing a mismatch and following warn:<br /> &gt; &gt; WARNING: CPU: 0 PID: 159 at lib/idr.c:525 ida_free+0x3e0/0x41f<br /> &gt; &gt; ida_free called for id=127 which is not allocated.<br /> &gt; &gt;

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: mmp2: call pm_genpd_init() only after genpd.name is set<br /> <br /> Setting the genpd&amp;#39;s struct device&amp;#39;s name with dev_set_name() is<br /> happening within pm_genpd_init(). If it remains NULL, things can blow up<br /> later, such as when crafting the devfs hierarchy for the power domain:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read<br /> ...<br /> Call trace:<br /> strlen from start_creating+0x90/0x138<br /> start_creating from debugfs_create_dir+0x20/0x178<br /> debugfs_create_dir from genpd_debug_add.part.0+0x4c/0x144<br /> genpd_debug_add.part.0 from genpd_debug_init+0x74/0x90<br /> genpd_debug_init from do_one_initcall+0x5c/0x244<br /> do_one_initcall from kernel_init_freeable+0x19c/0x1f4<br /> kernel_init_freeable from kernel_init+0x1c/0x12c<br /> kernel_init from ret_from_fork+0x14/0x28<br /> <br /> Bisecting tracks this crash back to commit 899f44531fe6 ("pmdomain: core:<br /> Add GENPD_FLAG_DEV_NAME_FW flag"), which exchanges use of genpd-&gt;name<br /> with dev_name(&amp;genpd-&gt;dev) in genpd_debug_add.part().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: qcom: scm: Fix missing read barrier in qcom_scm_get_tzmem_pool()<br /> <br /> Commit 2e4955167ec5 ("firmware: qcom: scm: Fix __scm and waitq<br /> completion variable initialization") introduced a write barrier in probe<br /> function to store global &amp;#39;__scm&amp;#39; variable. We all known barriers are<br /> paired (see memory-barriers.txt: "Note that write barriers should<br /> normally be paired with read or address-dependency barriers"), therefore<br /> accessing it from concurrent contexts requires read barrier. Previous<br /> commit added such barrier in qcom_scm_is_available(), so let&amp;#39;s use that<br /> directly.<br /> <br /> Lack of this read barrier can result in fetching stale &amp;#39;__scm&amp;#39; variable<br /> value, NULL, and dereferencing it.<br /> <br /> Note that barrier in qcom_scm_is_available() satisfies here the control<br /> dependency.

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 /> media: uvcvideo: Fix crash during unbind if gpio unit is in use<br /> <br /> We used the wrong device for the device managed functions. We used the<br /> usb device, when we should be using the interface device.<br /> <br /> If we unbind the driver from the usb interface, the cleanup functions<br /> are never called. In our case, the IRQ is never disabled.<br /> <br /> If an IRQ is triggered, it will try to access memory sections that are<br /> already free, causing an OOPS.<br /> <br /> We cannot use the function devm_request_threaded_irq here. The devm_*<br /> clean functions may be called after the main structure is released by<br /> uvc_delete.<br /> <br /> Luckily this bug has small impact, as it is only affected by devices<br /> with gpio units and the user has to unbind the device, a disconnect will<br /> not trigger this error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: qcom: dispcc-sm6350: Add missing parent_map for a clock<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 the clock 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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Explicitly verify target vCPU is online in kvm_get_vcpu()<br /> <br /> Explicitly verify the target vCPU is fully online _prior_ to clamping the<br /> index in kvm_get_vcpu(). If the index is "bad", the nospec clamping will<br /> generate &amp;#39;0&amp;#39;, i.e. KVM will return vCPU0 instead of NULL.<br /> <br /> In practice, the bug is unlikely to cause problems, as it will only come<br /> into play if userspace or the guest is buggy or misbehaving, e.g. KVM may<br /> send interrupts to vCPU0 instead of dropping them on the floor.<br /> <br /> However, returning vCPU0 when it shouldn&amp;#39;t exist per online_vcpus is<br /> problematic now that KVM uses an xarray for the vCPUs array, as KVM needs<br /> to insert into the xarray before publishing the vCPU to userspace (see<br /> commit c5b077549136 ("KVM: Convert the kvm-&gt;vcpus array to a xarray")),<br /> i.e. before vCPU creation is guaranteed to succeed.<br /> <br /> As a result, incorrectly providing access to vCPU0 will trigger a<br /> use-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu()<br /> bails out of vCPU creation due to an error and frees vCPU0. Commit<br /> afb2acb2e3a3 ("KVM: Fix vcpu_array[0] races") papered over that issue, but<br /> in doing so introduced an unsolvable teardown conundrum. Preventing<br /> accesses to vCPU0 before it&amp;#39;s fully online will allow reverting commit<br /> afb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tomoyo: don&amp;#39;t emit warning in tomoyo_write_control()<br /> <br /> syzbot is reporting too large allocation warning at tomoyo_write_control(),<br /> for one can write a very very long line without new line character. To fix<br /> this warning, I use __GFP_NOWARN rather than checking for KMALLOC_MAX_SIZE,<br /> for practically a valid line should be always shorter than 32KB where the<br /> "too small to fail" memory-allocation rule applies.<br /> <br /> One might try to write a valid line that is longer than 32KB, but such<br /> request will likely fail with -ENOMEM. Therefore, I feel that separately<br /> returning -EINVAL when a line is longer than KMALLOC_MAX_SIZE is redundant.<br /> There is no need to distinguish over-32KB and over-KMALLOC_MAX_SIZE.

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.