huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2024-57986: kernel: HID: core: Fix assumption that Resolution Multipliers must be in Logical Collections
Component: kernel
Severity: Moderate
CWE: CWE-20 (Improper Input Validation)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-27T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

HID: core: Fix assumption that Resolution Multipliers must be in Logical Collections

A report in 2019 by the syzbot fuzzer was found to be connected to two
errors in the HID core associated with Resolution Multipliers.  One of
the errors was fixed by commit ea427a222d8b ("HID: core: Fix deadloop
in hid_apply_multiplier."), but the other has not been fixed.

This error arises because hid_apply_multipler() assumes that every
Resolution Multiplier control is contained in a Logical Collection,
i.e., there's no way the routine can ever set multiplier_collection to
NULL.  This is in spite of the fact that the function starts with a
big comment saying:

	 * "The Resolution Multiplier control must be contained in the same
	 * Logical Collection as the control(s) to which it is to be applied.
	   ...
	 *  If no Logical Collection is
	 * defined, the Resolution Multiplier is associated with all
	 * controls in the report."
	 * HID Usage Table, v1.12, Section 4.3.1, p30
	 *
	 * Thus, search from the current collection upwards until we find a
	 * logical collection...

The comment and the code overlook the possibility that none of the
collections found may be a Logical Collection.

The fix is to set the multiplier_collection pointer to NULL if the
collection found isn't a Logical Collection.


Affected upstream versions: 5.0
Fixed upstream versions: 0, 5.10.235, 5.15.179, 5.4.291, 6.1.129, 6.12.13, 6.13.2, 6.14, 6.6.76
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 3a002e4029230d9a6be89f869b2328b258612f5c
CVE-2024-57987: kernel: Bluetooth: btrtl: check for NULL in btrtl_setup_realtek()
Component: kernel
Severity: Moderate
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-27T00:00:00+00:00

A NULL pointer access may result in compromised availability.


Affected upstream versions: 6.10
Fixed upstream versions: 0, 6.12.13, 6.13.2, 6.14
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 1158ad8e8abb361d4b2aaa010c9af74de20ab82b
CVE-2024-57988: kernel: Bluetooth: btbcm: Fix NULL deref in btbcm_get_board_name()
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-27T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btbcm: Fix NULL deref in btbcm_get_board_name()

devm_kstrdup() can return a NULL pointer on failure,but this
returned value in btbcm_get_board_name() is not checked.
Add NULL check in btbcm_get_board_name(), to handle kernel NULL
pointer dereference error.


Affected upstream versions: 6.9
Fixed upstream versions: 0, 6.12.13, 6.13.2, 6.14
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: df2f2d9199e61819cca5da0121dfa4d4cb57000f
CVE-2024-57989: kernel: wifi: mt76: mt7925: fix NULL deref check in mt7925_change_vif_links
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-27T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7925: fix NULL deref check in mt7925_change_vif_links

In mt7925_change_vif_links() devm_kzalloc() may return NULL but this
returned value is not checked.


Affected upstream versions: 6.11
Fixed upstream versions: 0, 6.12.13, 6.13.2, 6.14
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 5872530c2862700070223a2c2ea85642bf2f8875
CVE-2024-57990: kernel: wifi: mt76: mt7925: fix off by one in mt7925_load_clc()
Component: kernel
Severity: Moderate
CWE: CWE-193 (Off-by-one Error)
CVSS v3: 7.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H)
Public date: 2025-02-27T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7925: fix off by one in mt7925_load_clc()

This comparison should be >= instead of > to prevent an out of bounds
read and write.


Affected upstream versions: 6.10.13 < 6.11, 6.11.2 < 6.12, 6.12
Fixed upstream versions: 0, 6.11, 6.12, 6.12.13, 6.13.2, 6.14
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: d03b8fe1b518fc2ea2d82588e905f56d80cd64b2
CVE-2024-57993: kernel: HID: hid-thrustmaster: Fix warning in thrustmaster_probe by adding endpoint check
Component: kernel
Severity: Low
CWE: CWE-20 (Improper Input Validation)
CVSS v3: 3.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L)
Public date: 2025-02-27T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

HID: hid-thrustmaster: Fix warning in thrustmaster_probe by adding endpoint check

syzbot has found a type mismatch between a USB pipe and the transfer
endpoint, which is triggered by the hid-thrustmaster driver[1].
There is a number of similar, already fixed issues [2].
In this case as in others, implementing check for endpoint type fixes the issue.

[1] https://syzkaller.appspot.com/bug?extid=040e8b3db6a96908d470
[2] https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622


Affected upstream versions: 5.13
Fixed upstream versions: 0, 6.1.129, 6.12.13, 6.13.2, 6.14, 6.6.76
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 220883fba32549a34f0734e4859d07f4dcd56992
CVE-2024-57995: kernel: wifi: ath12k: fix read pointer after free in ath12k_mac_assign_vif_to_vdev()
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 6.7 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-02-27T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: fix read pointer after free in ath12k_mac_assign_vif_to_vdev()

In ath12k_mac_assign_vif_to_vdev(), if arvif is created on a different
radio, it gets deleted from that radio through a call to
ath12k_mac_unassign_link_vif(). This action frees the arvif pointer.
Subsequently, there is a check involving arvif, which will result in a
read-after-free scenario.

Fix this by moving this check after arvif is again assigned via call to
ath12k_mac_assign_link_vif().

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1


Affected upstream versions: 6.10
Fixed upstream versions: 0, 6.12.57, 6.13.2, 6.14
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 57100b87c77818cb0d582a92e5cb32fff85c757d
CVE-2024-57998: kernel: OPP: add index check to assert to avoid buffer overflow in _read_freq()
Component: kernel
Severity: Moderate
CWE: CWE-120 (Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'))
CVSS v3: 7.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H)
Public date: 2025-02-27T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

OPP: add index check to assert to avoid buffer overflow in _read_freq()

Pass the freq index to the assert function to make sure
we do not read a freq out of the opp->rates[] table when called
from the indexed variants:
dev_pm_opp_find_freq_exact_indexed() or
dev_pm_opp_find_freq_ceil/floor_indexed().

Add a secondary parameter to the assert function, unused
for assert_single_clk() then add assert_clk_index() which
will check for the clock index when called from the _indexed()
find functions.


Affected upstream versions: 6.6
Fixed upstream versions: 0, 6.12.13, 6.13.2, 6.14, 6.6.76
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 774dd6f0f0a61c9c3848e025d7d9eeed1a7ca4cd
CVE-2024-58002: kernel: media: uvcvideo: Remove dangling pointers
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 7.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H)
Public date: 2025-02-27T00:00:00+00:00

A dangling pointer vulnerability was found in the Linux kernel. When an async control is written, a copy of a pointer is made in the file handle that started the operation. If the user closes that file descriptor, its structure will be freed and there will be one dangling pointer per pending async control that the driver will try to use, leading to denial of service of the system.

Statement: A use after free problem was seen in uvc_ctrl_status_event in USB Video Class (UVC) driver. This flaw could allow a local normal user (which no special privilege) to crash the system at time of device closure. This vulnerability could even lead to a kernel information leak problem.

Affected upstream versions: 4.19
Fixed upstream versions: 0, 5.10.235, 5.15.179, 5.4.291, 6.1.130, 6.12.14, 6.13.3, 6.14, 6.6.80
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 2a29413ace64627e178fd422dd8a5d95219a2c0b
CVE-2024-58004: kernel: media: intel/ipu6: remove cpu latency qos request on error
Component: kernel
Severity: Moderate
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-27T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

media: intel/ipu6: remove cpu latency qos request on error

Fix cpu latency qos list corruption like below. It happens when
we do not remove cpu latency request on error path and free
corresponding memory.

[   30.634378] l7 kernel: list_add corruption. prev->next should be next (ffffffff9645e960), but was 0000000100100001. (prev=ffff8e9e877e20a8).
[   30.634388] l7 kernel: WARNING: CPU: 2 PID: 2008 at lib/list_debug.c:32 __list_add_valid_or_report+0x83/0xa0
<snip>
[   30.634640] l7 kernel: Call Trace:
[   30.634650] l7 kernel:  <TASK>
[   30.634659] l7 kernel:  ? __list_add_valid_or_report+0x83/0xa0
[   30.634669] l7 kernel:  ? __warn.cold+0x93/0xf6
[   30.634678] l7 kernel:  ? __list_add_valid_or_report+0x83/0xa0
[   30.634690] l7 kernel:  ? report_bug+0xff/0x140
[   30.634702] l7 kernel:  ? handle_bug+0x58/0x90
[   30.634712] l7 kernel:  ? exc_invalid_op+0x17/0x70
[   30.634723] l7 kernel:  ? asm_exc_invalid_op+0x1a/0x20
[   30.634733] l7 kernel:  ? __list_add_valid_or_report+0x83/0xa0
[   30.634742] l7 kernel:  plist_add+0xdd/0x140
[   30.634754] l7 kernel:  pm_qos_update_target+0xa0/0x1f0
[   30.634764] l7 kernel:  cpu_latency_qos_update_request+0x61/0xc0
[   30.634773] l7 kernel:  intel_dp_aux_xfer+0x4c7/0x6e0 [i915 1f824655ed04687c2b0d23dbce759fa785f6d033]


Affected upstream versions: 6.10
Fixed upstream versions: 0, 6.12.14, 6.13.3, 6.14
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 1496ec94bd38bdb25ca13b1dd4f8e7a6176ea89d
CVE-2024-58005: kernel: tpm: Change to kvalloc() in eventlog/acpi.c
Component: kernel
Severity: Moderate
CWE: CWE-99 (Improper Control of Resource Identifiers ('Resource Injection'))
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-27T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

tpm: Change to kvalloc() in eventlog/acpi.c

The following failure was reported on HPE ProLiant D320:

[   10.693310][    T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0)
[   10.848132][    T1] ------------[ cut here ]------------
[   10.853559][    T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330
[   10.862827][    T1] Modules linked in:
[   10.866671][    T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375
[   10.882741][    T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024
[   10.892170][    T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330
[   10.898103][    T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1
[   10.917750][    T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246
[   10.923777][    T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000
[   10.931727][    T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0

The above transcript shows that ACPI pointed a 16 MiB buffer for the log
events because RSI maps to the 'order' parameter of __alloc_pages_noprof().
Address the bug by moving from devm_kmalloc() to devm_add_action() and
kvmalloc() and devm_add_action().


Affected upstream versions: 2.6.16
Fixed upstream versions: 0, 5.10.235, 5.15.179, 6.1.130, 6.12.14, 6.13.3, 6.14, 6.6.78
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: a676c0401de59548a5bc1b7aaf98f556ae8ea6db
CVE-2024-58006: kernel: PCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar()
Component: kernel
Severity: Moderate
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-27T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

PCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar()

In commit 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update
inbound map address") set_bar() was modified to support dynamically
changing the backing physical address of a BAR that was already configured.

This means that set_bar() can be called twice, without ever calling
clear_bar() (as calling clear_bar() would clear the BAR's PCI address
assigned by the host).

This can only be done if the new BAR size/flags does not differ from the
existing BAR configuration. Add these missing checks.

If we allow set_bar() to set e.g. a new BAR size that differs from the
existing BAR size, the new address translation range will be smaller than
the BAR size already determined by the host, which would mean that a read
past the new BAR size would pass the iATU untranslated, which could allow
the host to read memory not belonging to the new struct pci_epf_bar.

While at it, add comments which clarifies the support for dynamically
changing the physical address of a BAR. (Which was also missing.)


Affected upstream versions: 6.0
Fixed upstream versions: 0, 6.12.14, 6.13.3, 6.14
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: b5cacfd067060c75088363ed3e19779078be2755
CVE-2024-58007: kernel: soc: qcom: socinfo: Avoid out of bounds read of serial number
Component: kernel
Severity: Moderate
CWE: CWE-125 (Out-of-bounds Read)
CVSS v3: 7.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H)
Public date: 2025-02-27T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

soc: qcom: socinfo: Avoid out of bounds read of serial number

On MSM8916 devices, the serial number exposed in sysfs is constant and does
not change across individual devices. It's always:

  db410c:/sys/devices/soc0$ cat serial_number
  2644893864

The firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does not
have support for the serial_num field in the socinfo struct. There is an
existing check to avoid exposing the serial number in that case, but it's
not correct: When checking the item_size returned by SMEM, we need to make
sure the *end* of the serial_num is within bounds, instead of comparing
with the *start* offset. The serial_number currently exposed on MSM8916
devices is just an out of bounds read of whatever comes after the socinfo
struct in SMEM.

Fix this by changing offsetof() to offsetofend(), so that the size of the
field is also taken into account.


Affected upstream versions: 5.4
Fixed upstream versions: 0, 5.10.235, 5.15.179, 5.4.291, 6.1.129, 6.12.14, 6.13.3, 6.14, 6.6.78
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 7445fa05317534bbd8b373c0eff8319187916030
CVE-2024-58009: kernel: Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_alloc
Component: kernel
Severity: Low
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-27T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_alloc

A NULL sock pointer is passed into l2cap_sock_alloc() when it is called
from l2cap_sock_new_connection_cb() and the error handling paths should
also be aware of it.

Seemingly a more elegant solution would be to swap bt_sock_alloc() and
l2cap_chan_create() calls since they are not interdependent to that moment
but then l2cap_chan_create() adds the soon to be deallocated and still
dummy-initialized channel to the global list accessible by many L2CAP
paths. The channel would be removed from the list in short period of time
but be a bit more straight-forward here and just check for NULL instead of
changing the order of function calls.

Found by Linux Verification Center (linuxtesting.org) with SVACE static
analysis tool.


Affected upstream versions: 5.4.287 < 5.4.291, 5.10.231 < 5.10.235, 5.15.174 < 5.15.179, 6.1.120 < 6.1.129, 6.6.66 < 6.6.78, 6.12.5 < 6.12.14, 6.13
Fixed upstream versions: 0, 5.10.235, 5.15.179, 5.4.291, 6.1.129, 6.12.14, 6.13.3, 6.14, 6.6.78
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: a9a7672fc1a0fe18502493936ccb06413ab89ea6
CVE-2024-58012: kernel: ASoC: SOF: Intel: hda-dai: Ensure DAI widget is valid during params
Component: kernel
Severity: Low
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-27T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

ASoC: SOF: Intel: hda-dai: Ensure DAI widget is valid during params

Each cpu DAI should associate with a widget. However, the topology might
not create the right number of DAI widgets for aggregated amps. And it
will cause NULL pointer deference.
Check that the DAI widget associated with the CPU DAI is valid to prevent
NULL pointer deference due to missing DAI widgets in topologies with
aggregated amps.


Affected upstream versions: 5.7
Fixed upstream versions: 0, 6.12.14, 6.13.3, 6.14
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: e012a77e4d7632cf615ba9625b1600ed8985c3b5
CVE-2024-58014: kernel: wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy()
Component: kernel
Severity: Moderate
CWE: CWE-125 (Out-of-bounds Read)
CVSS v3: 6 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:H)
Public date: 2025-02-27T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy()

In 'wlc_phy_iqcal_gainparams_nphy()', add gain range check to WARN()
instead of possible out-of-bounds 'tbl_iqcal_gainparams_nphy' access.
Compile tested only.

Found by Linux Verification Center (linuxtesting.org) with SVACE.


Affected upstream versions: 3.2
Fixed upstream versions: 0, 5.10.235, 5.15.179, 5.4.291, 6.1.129, 6.12.14, 6.13.3, 6.14, 6.6.78
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 0a457223cb2b9ca46bae7de387d0f4c093b0220d
CVE-2024-58015: kernel: wifi: ath12k: Fix for out-of bound access error
Component: kernel
Severity: Moderate
CWE: CWE-125 (Out-of-bounds Read)
CVSS v3: 6 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:H)
Public date: 2025-02-27T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: Fix for out-of bound access error

Selfgen stats are placed in a buffer using print_array_to_buf_index() function.
Array length parameter passed to the function is too big, resulting in possible
out-of bound memory error.
Decreasing buffer size by one fixes faulty upper bound of passed array.

Discovered in coverity scan, CID 1600742 and CID 1600758


Affected upstream versions: 6.3
Fixed upstream versions: 0, 6.13.3, 6.14
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 8700c4bf8b7ed98037d2acf1eaf770ad6dd431d4
CVE-2024-58020: kernel: HID: multitouch: Add NULL check in mt_input_configured
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-27T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

HID: multitouch: Add NULL check in mt_input_configured

devm_kasprintf() can return a NULL pointer on failure,but this
returned value in mt_input_configured() is not checked.
Add NULL check in mt_input_configured(), to handle kernel NULL
pointer dereference error.


Affected upstream versions: 5.4.257 < 5.4.291, 5.10.195 < 5.10.235, 5.15.132 < 5.15.179, 6.1.53 < 6.1.129, 4.14.326 < 4.15, 4.19.295 < 4.20, 6.4.16 < 6.5, 6.5.3 < 6.6, 6.6
Fixed upstream versions: 0, 4.15, 4.20, 5.10.235, 5.15.179, 5.4.291, 6.1.129, 6.12.16, 6.13.4, 6.14, 6.5, 6.6, 6.6.79
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: a04d96ef67a42165f93194eef22a270acba4b74c
CVE-2024-58057: kernel: idpf: convert workqueues to unbound
Component: kernel
Severity: Moderate
CWE: CWE-400 (Uncontrolled Resource Consumption)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-03-06T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

idpf: convert workqueues to unbound

When a workqueue is created with `WQ_UNBOUND`, its work items are
served by special worker-pools, whose host workers are not bound to
any specific CPU. In the default configuration (i.e. when
`queue_delayed_work` and friends do not specify which CPU to run the
work item on), `WQ_UNBOUND` allows the work item to be executed on any
CPU in the same node of the CPU it was enqueued on. While this
solution potentially sacrifices locality, it avoids contention with
other processes that might dominate the CPU time of the processor the
work item was scheduled on.

This is not just a theoretical problem: in a particular scenario
misconfigured process was hogging most of the time from CPU0, leaving
less than 0.5% of its CPU time to the kworker. The IDPF workqueues
that were using the kworker on CPU0 suffered large completion delays
as a result, causing performance degradation, timeouts and eventual
system crash.


* I have also run a manual test to gauge the performance
  improvement. The test consists of an antagonist process
  (`./stress --cpu 2`) consuming as much of CPU 0 as possible. This
  process is run under `taskset 01` to bind it to CPU0, and its
  priority is changed with `chrt -pQ 9900 10000 ${pid}` and
  `renice -n -20 ${pid}` after start.

  Then, the IDPF driver is forced to prefer CPU0 by editing all calls
  to `queue_delayed_work`, `mod_delayed_work`, etc... to use CPU 0.

  Finally, `ktraces` for the workqueue events are collected.

  Without the current patch, the antagonist process can force
  arbitrary delays between `workqueue_queue_work` and
  `workqueue_execute_start`, that in my tests were as high as
  `30ms`. With the current patch applied, the workqueue can be
  migrated to another unloaded CPU in the same node, and, keeping
  everything else equal, the maximum delay I could see was `6us`.


Affected upstream versions: 6.7
Fixed upstream versions: 0, 6.12.13, 6.13.2, 6.14
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 66bf9b3d9e1658333741f075320dc8e7cd6f8d09