Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> safesetid: check size of policy writes<br /> <br /> syzbot attempts to write a buffer with a large size to a sysfs entry<br /> with writes handled by handle_policy_update(), triggering a warning<br /> in kmalloc.<br /> <br /> Check the size specified for write buffers before allocating.<br /> <br /> [PM: subject tweak]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> printk: Fix signed integer overflow when defining LOG_BUF_LEN_MAX<br /> <br /> Shifting 1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: multitouch: Add NULL check in mt_input_configured<br /> <br /> devm_kasprintf() can return a NULL pointer on failure,but this<br /> returned value in mt_input_configured() is not checked.<br /> Add NULL check in mt_input_configured(), to handle kernel NULL<br /> pointer dereference error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: i2c: ds90ub9x3: Fix extra fwnode_handle_put()<br /> <br /> The ub913 and ub953 drivers call fwnode_handle_put(priv-&gt;sd.fwnode) as<br /> part of their remove process, and if the driver is removed multiple<br /> times, eventually leads to put "overflow", possibly causing memory<br /> corruption or crash.<br /> <br /> The fwnode_handle_put() is a leftover from commit 905f88ccebb1 ("media:<br /> i2c: ds90ub9x3: Fix sub-device matching"), which changed the code<br /> related to the sd.fwnode, but missed removing these fwnode_handle_put()<br /> calls.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: intel/ipu6: remove cpu latency qos request on error<br /> <br /> Fix cpu latency qos list corruption like below. It happens when<br /> we do not remove cpu latency request on error path and free<br /> corresponding memory.<br /> <br /> [ 30.634378] l7 kernel: list_add corruption. prev-&gt;next should be next (ffffffff9645e960), but was 0000000100100001. (prev=ffff8e9e877e20a8).<br /> [ 30.634388] l7 kernel: WARNING: CPU: 2 PID: 2008 at lib/list_debug.c:32 __list_add_valid_or_report+0x83/0xa0<br /> <br /> [ 30.634640] l7 kernel: Call Trace:<br /> [ 30.634650] l7 kernel: <br /> [ 30.634659] l7 kernel: ? __list_add_valid_or_report+0x83/0xa0<br /> [ 30.634669] l7 kernel: ? __warn.cold+0x93/0xf6<br /> [ 30.634678] l7 kernel: ? __list_add_valid_or_report+0x83/0xa0<br /> [ 30.634690] l7 kernel: ? report_bug+0xff/0x140<br /> [ 30.634702] l7 kernel: ? handle_bug+0x58/0x90<br /> [ 30.634712] l7 kernel: ? exc_invalid_op+0x17/0x70<br /> [ 30.634723] l7 kernel: ? asm_exc_invalid_op+0x1a/0x20<br /> [ 30.634733] l7 kernel: ? __list_add_valid_or_report+0x83/0xa0<br /> [ 30.634742] l7 kernel: plist_add+0xdd/0x140<br /> [ 30.634754] l7 kernel: pm_qos_update_target+0xa0/0x1f0<br /> [ 30.634764] l7 kernel: cpu_latency_qos_update_request+0x61/0xc0<br /> [ 30.634773] l7 kernel: intel_dp_aux_xfer+0x4c7/0x6e0 [i915 1f824655ed04687c2b0d23dbce759fa785f6d033]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar()<br /> <br /> In commit 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update<br /> inbound map address") set_bar() was modified to support dynamically<br /> changing the backing physical address of a BAR that was already configured.<br /> <br /> This means that set_bar() can be called twice, without ever calling<br /> clear_bar() (as calling clear_bar() would clear the BAR&amp;#39;s PCI address<br /> assigned by the host).<br /> <br /> This can only be done if the new BAR size/flags does not differ from the<br /> existing BAR configuration. Add these missing checks.<br /> <br /> If we allow set_bar() to set e.g. a new BAR size that differs from the<br /> existing BAR size, the new address translation range will be smaller than<br /> the BAR size already determined by the host, which would mean that a read<br /> past the new BAR size would pass the iATU untranslated, which could allow<br /> the host to read memory not belonging to the new struct pci_epf_bar.<br /> <br /> While at it, add comments which clarifies the support for dynamically<br /> changing the physical address of a BAR. (Which was also missing.)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KEYS: trusted: dcp: fix improper sg use with CONFIG_VMAP_STACK=y<br /> <br /> With vmalloc stack addresses enabled (CONFIG_VMAP_STACK=y) DCP trusted<br /> keys can crash during en- and decryption of the blob encryption key via<br /> the DCP crypto driver. This is caused by improperly using sg_init_one()<br /> with vmalloc&amp;#39;d stack buffers (plain_key_blob).<br /> <br /> Fix this by always using kmalloc() for buffers we give to the DCP crypto<br /> driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: handle a symlink read error correctly<br /> <br /> Patch series "Convert ocfs2 to use folios".<br /> <br /> Mark did a conversion of ocfs2 to use folios and sent it to me as a<br /> giant patch for review ;-)<br /> <br /> So I&amp;#39;ve redone it as individual patches, and credited Mark for the patches<br /> where his code is substantially the same. It&amp;#39;s not a bad way to do it;<br /> his patch had some bugs and my patches had some bugs. Hopefully all our<br /> bugs were different from each other. And hopefully Mark likes all the<br /> changes I made to his code!<br /> <br /> <br /> This patch (of 23):<br /> <br /> If we can&amp;#39;t read the buffer, be sure to unlock the page before returning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: uvcvideo: Remove dangling pointers<br /> <br /> When an async control is written, we copy a pointer to the file handle<br /> that started the operation. That pointer will be used when the device is<br /> done. Which could be anytime in the future.<br /> <br /> If the user closes that file descriptor, its structure will be freed,<br /> and there will be one dangling pointer per pending async control, that<br /> the driver will try to use.<br /> <br /> Clean all the dangling pointers during release().<br /> <br /> To avoid adding a performance penalty in the most common case (no async<br /> operation), a counter has been introduced with some logic to make sure<br /> that it is properly handled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: qcom: socinfo: Avoid out of bounds read of serial number<br /> <br /> On MSM8916 devices, the serial number exposed in sysfs is constant and does<br /> not change across individual devices. It&amp;#39;s always:<br /> <br /> db410c:/sys/devices/soc0$ cat serial_number<br /> 2644893864<br /> <br /> The firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does not<br /> have support for the serial_num field in the socinfo struct. There is an<br /> existing check to avoid exposing the serial number in that case, but it&amp;#39;s<br /> not correct: When checking the item_size returned by SMEM, we need to make<br /> sure the *end* of the serial_num is within bounds, instead of comparing<br /> with the *start* offset. The serial_number currently exposed on MSM8916<br /> devices is just an out of bounds read of whatever comes after the socinfo<br /> struct in SMEM.<br /> <br /> Fix this by changing offsetof() to offsetofend(), so that the size of the<br /> field is also taken into account.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binfmt_flat: Fix integer overflow bug on 32 bit systems<br /> <br /> Most of these sizes and counts are capped at 256MB so the math doesn&amp;#39;t<br /> result in an integer overflow. The "relocs" count needs to be checked<br /> as well. Otherwise on 32bit systems the calculation of "full_data"<br /> could be wrong.<br /> <br /> full_data = data_len + relocs * sizeof(unsigned long);

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tpm: Change to kvalloc() in eventlog/acpi.c<br /> <br /> The following failure was reported on HPE ProLiant D320:<br /> <br /> [ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0)<br /> [ 10.848132][ T1] ------------[ cut here ]------------<br /> [ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330<br /> [ 10.862827][ T1] Modules linked in:<br /> [ 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<br /> [ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024<br /> [ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330<br /> [ 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 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1<br /> [ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246<br /> [ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000<br /> [ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0<br /> <br /> The above transcript shows that ACPI pointed a 16 MiB buffer for the log<br /> events because RSI maps to the &amp;#39;order&amp;#39; parameter of __alloc_pages_noprof().<br /> Address the bug by moving from devm_kmalloc() to devm_add_action() and<br /> kvmalloc() and devm_add_action().