Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iomap: add a separate bio_set for iomap_split_ioend<br /> <br /> iomap_split_ioend can split bios that already come from<br /> iomap_ioend_bioset and thus deadlock when the bioset is exhausted.<br /> <br /> Add a separate bio_set to avoid this deadlock.<br /> <br /> Christian Brauner says:<br /> Mark iomap_ioend_split_bioset static as it is only used in ioend.c,<br /> fixing the sparse warning reported by the kernel test robot.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: ISO: ensure no dangling hcon references in iso_conn<br /> <br /> After iso_conn_del(), ISO sockets should not dereference the hcon any<br /> more. Currently, clearing iso_conn::hcon relies on iso_conn_del()<br /> releasing the last reference to the iso_conn.<br /> <br /> Simplify this by explicitly clearing conn-&gt;hcon in iso_conn_del(), to<br /> avoid more complex reasoning on races about who holds the last<br /> reference.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: check if dml21_add_phantom_plane() is successful<br /> <br /> Verify that the phantom plane was allocated to avoid a later<br /> segfault.<br /> <br /> (cherry picked from commit 5adb54abe5a8e82cbff7f8806db30a5f4924329f)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: softing: fw_parse(): validate firmware record spans<br /> <br /> fw_parse() reads a fixed record header, a firmware-provided payload,<br /> and a trailing checksum without knowing the end of the firmware blob. A<br /> truncated record can therefore make those reads exceed the blob.<br /> <br /> The same record also supplies addresses and lengths for writes into<br /> DPRAM. The generic loader uses wrap-prone mixed signed arithmetic for its<br /> bounds check, while the application loader does not bound the staging<br /> copy at all.<br /> <br /> Pass the firmware end to the parser and validate the full source record.<br /> Use a signed wide offset for generic DPRAM records and validate the<br /> application staging span against the mapped DPRAM before copying.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: j1939: transport: j1939_session_fresh_new(): initialize receive buffer<br /> <br /> Zero the allocated buffer in j1939_session_fresh_new() to ensure it<br /> contains no residual data.<br /> <br /> While there is a potential performance impact if users allocate maximum<br /> sized ETP buffers, most real-world use cases are not noticeably affected<br /> since the maximum known buffer size is typically around 65K.<br /> <br /> [mkl: add Message-ID]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/zcrypt: Fix missing mem scrub at clear key import in cca_clr2cipherkey()<br /> <br /> The helper function _ip_cprb_helper() uses internal buffer memory for<br /> building and processing CPRBs. After use this buffer was never<br /> scrubbed which could lead to leaving for example clear key material in<br /> memory which could be exposed via tricky reuse of this same memory.<br /> <br /> Extend the _ip_cprb_helper() function with another parameter &amp;#39;scrub&amp;#39;<br /> used to steer scrubbing of this buffer. So now the caller has the<br /> opportunity to decide if scrubbing is needed or not.<br /> <br /> Extend the clear key to secure key token import process in function<br /> cca_clr2cipherkey() to tell the helper function from above to scrub<br /> the cprb buffer when the clear key value is part of the request data.<br /> <br /> Add explicit scrubbing on return from function cca_clr2cipherkey() for<br /> the random EXOR buffer and the cprb buffer.<br /> <br /> Overall this cleans the internal used buffer in case of clear key<br /> import to prevent sensitive data to get exposed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/zcrypt: Fix wrong domain value verification with EP11 CPRBs<br /> <br /> There is a wrong upper limit check for the domain value when an EP11<br /> CPRB is processed for sending to a crypto card. This check is only<br /> active on custom device nodes but may lead to access heap memory<br /> behind perms-&gt;adm when an administrative CPRB is sent.<br /> Add correct limit (AP_DOMAINS = 256) checking to fix this.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/dasd: Fix undersized format-check buffer<br /> <br /> fmt_buffer_size in dasd_eckd_check_device_format() is declared as<br /> int, even though one of the multiplicands, sizeof(struct eckd_count),<br /> is a size_t. The expression<br /> <br /> trkcount * rpt_max * sizeof(struct eckd_count)<br /> <br /> is therefore correctly evaluated at 64-bit width, but the result is<br /> silently truncated when it is stored back into the 32-bit<br /> fmt_buffer_size variable. For a sufficiently large track range<br /> (start_unit/stop_unit are caller-controlled) this truncation<br /> yields a buffer size far smaller than the number of tracks actually<br /> requested. kzalloc() then succeeds with an undersized allocation,<br /> while the subsequent channel program build still operates on the<br /> untruncated track count and writes past the end of that buffer.<br /> <br /> Compute the buffer size with check_mul_overflow() and keep it in a<br /> size_t, so that a value that no longer fits results in -EINVAL<br /> instead of a silently truncated allocation size.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: max17040: handle missing status supplier<br /> <br /> MAX17040 does not report charger state itself, so the driver forwards<br /> POWER_SUPPLY_PROP_STATUS to a supplier power supply. If no supplier is<br /> registered, power_supply_get_property_from_supplier() returns -ENODEV and<br /> leaves the output value untouched.<br /> <br /> max17040_get_property() currently ignores that error and returns success,<br /> so userspace can read an uninitialized status value from the battery power<br /> supply. This happens on systems that use the fuel gauge without a charger<br /> supplier relationship in firmware.<br /> <br /> Return POWER_SUPPLY_STATUS_UNKNOWN when no supplier provides STATUS, and<br /> propagate other supplier lookup errors.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: spi-qpic-snand: write the feature value before executing SET_FEATURE<br /> <br /> qcom_spi_send_cmdaddr() programs NAND_FLASH_CMD/NAND_EXEC_CMD and submits<br /> the descriptors, which makes the controller execute the command<br /> immediately. For SPINAND_SET_FEATURE the value to be written is only<br /> placed into NAND_FLASH_FEATURES afterwards, by qcom_spi_io_op(), in a<br /> second submission - so the chip is programmed with whatever that register<br /> happened to hold from a previous operation, and the intended value is only<br /> applied by the *next* SET_FEATURE.<br /> <br /> Measured on a TP-Link Archer AX55 v1 (IPQ5018, ESMT F50L1G41LB): writing<br /> 0x40 to the configuration register (0xb0) leaves the chip at 0x00, and the<br /> subsequent write of 0x00 leaves it at 0x40 - every write lands one<br /> operation late.<br /> <br /> This stayed unnoticed until v6.18 added SPI-NAND OTP support together<br /> with OTP entries for ESMT chips. spinand_otp_rw() enables OTP mode,<br /> reads, and disables it again, and mtd_otp_nvmem_add() does this during<br /> MTD registration. With the off-by-one, the "disable" write actually<br /> applies the previously requested value, so CFG_OTP_ENABLE ends up set:<br /> the chip stays in OTP mode, every subsequent array read returns the OTP<br /> area instead of the array (UBI reports an empty device) and all writes<br /> fail with -EIO because the OTP area is write protected. On this board<br /> that makes the whole flash unusable and the device unbootable.<br /> <br /> Write the feature value into NAND_FLASH_FEATURES as part of the same<br /> transaction, before NAND_EXEC_CMD. While at it, copy only the bytes the<br /> operation actually carries - the previous code dereferenced a 4-byte<br /> pointer on a one-byte buffer (spinand-&gt;scratchbuf).<br /> <br /> With this patch the flash contents read back bit-identical to a<br /> known-good dump of the same board taken under the vendor firmware<br /> (md5-verified across partitions), and writes work.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: preserve task restrictions across exec<br /> <br /> Per-task restrictions apply to all rings created by a task. Once<br /> installed, they should not be dropped across exec.<br /> <br /> For a task that has used io_uring, the exec cancellation path calls<br /> __io_uring_free(). This frees both the task context and the per-task<br /> restriction, so a ring created after exec is unrestricted.<br /> <br /> Split task context cleanup into io_uring_free_tctx(), and use it from<br /> the exec cancellation path. Keep __io_uring_free() for final task<br /> cleanup, where both the context and restriction are released.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (ltc4282) Fix reading the minimum alarm voltage<br /> <br /> Coverity reports an out-of-bounds access when reading the minimum alarm<br /> voltage for the VGPIO channel. Add the missing return statement to fix<br /> the problem.