CVE-2026-80705 - drm/amd/display: check if dml21_add_phantom_plane() is successful
CVE ID :CVE-2026-80705
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: check if dml21_add_phantom_plane() is successful Verify that the phantom plane was allocated to avoid a later segfault. (cherry picked from commit 5adb54abe5a8e82cbff7f8806db30a5f4924329f)
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-80705
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: check if dml21_add_phantom_plane() is successful Verify that the phantom plane was allocated to avoid a later segfault. (cherry picked from commit 5adb54abe5a8e82cbff7f8806db30a5f4924329f)
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-80706 - can: softing: fw_parse(): validate firmware record spans
CVE ID :CVE-2026-80706
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: can: softing: fw_parse(): validate firmware record spans fw_parse() reads a fixed record header, a firmware-provided payload, and a trailing checksum without knowing the end of the firmware blob. A truncated record can therefore make those reads exceed the blob. The same record also supplies addresses and lengths for writes into DPRAM. The generic loader uses wrap-prone mixed signed arithmetic for its bounds check, while the application loader does not bound the staging copy at all. Pass the firmware end to the parser and validate the full source record. Use a signed wide offset for generic DPRAM records and validate the application staging span against the mapped DPRAM before copying.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-80706
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: can: softing: fw_parse(): validate firmware record spans fw_parse() reads a fixed record header, a firmware-provided payload, and a trailing checksum without knowing the end of the firmware blob. A truncated record can therefore make those reads exceed the blob. The same record also supplies addresses and lengths for writes into DPRAM. The generic loader uses wrap-prone mixed signed arithmetic for its bounds check, while the application loader does not bound the staging copy at all. Pass the firmware end to the parser and validate the full source record. Use a signed wide offset for generic DPRAM records and validate the application staging span against the mapped DPRAM before copying.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-80707 - can: j1939: transport: j1939_session_fresh_new(): initialize receive buffer
CVE ID :CVE-2026-80707
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: can: j1939: transport: j1939_session_fresh_new(): initialize receive buffer Zero the allocated buffer in j1939_session_fresh_new() to ensure it contains no residual data. While there is a potential performance impact if users allocate maximum sized ETP buffers, most real-world use cases are not noticeably affected since the maximum known buffer size is typically around 65K. [mkl: add Message-ID]
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-80707
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: can: j1939: transport: j1939_session_fresh_new(): initialize receive buffer Zero the allocated buffer in j1939_session_fresh_new() to ensure it contains no residual data. While there is a potential performance impact if users allocate maximum sized ETP buffers, most real-world use cases are not noticeably affected since the maximum known buffer size is typically around 65K. [mkl: add Message-ID]
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-80708 - s390/zcrypt: Fix missing mem scrub at clear key import in cca_clr2cipherkey()
CVE ID :CVE-2026-80708
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Fix missing mem scrub at clear key import in cca_clr2cipherkey() The helper function _ip_cprb_helper() uses internal buffer memory for building and processing CPRBs. After use this buffer was never scrubbed which could lead to leaving for example clear key material in memory which could be exposed via tricky reuse of this same memory. Extend the _ip_cprb_helper() function with another parameter 'scrub' used to steer scrubbing of this buffer. So now the caller has the opportunity to decide if scrubbing is needed or not. Extend the clear key to secure key token import process in function cca_clr2cipherkey() to tell the helper function from above to scrub the cprb buffer when the clear key value is part of the request data. Add explicit scrubbing on return from function cca_clr2cipherkey() for the random EXOR buffer and the cprb buffer. Overall this cleans the internal used buffer in case of clear key import to prevent sensitive data to get exposed.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-80708
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Fix missing mem scrub at clear key import in cca_clr2cipherkey() The helper function _ip_cprb_helper() uses internal buffer memory for building and processing CPRBs. After use this buffer was never scrubbed which could lead to leaving for example clear key material in memory which could be exposed via tricky reuse of this same memory. Extend the _ip_cprb_helper() function with another parameter 'scrub' used to steer scrubbing of this buffer. So now the caller has the opportunity to decide if scrubbing is needed or not. Extend the clear key to secure key token import process in function cca_clr2cipherkey() to tell the helper function from above to scrub the cprb buffer when the clear key value is part of the request data. Add explicit scrubbing on return from function cca_clr2cipherkey() for the random EXOR buffer and the cprb buffer. Overall this cleans the internal used buffer in case of clear key import to prevent sensitive data to get exposed.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-80709 - s390/zcrypt: Fix wrong domain value verification with EP11 CPRBs
CVE ID :CVE-2026-80709
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Fix wrong domain value verification with EP11 CPRBs There is a wrong upper limit check for the domain value when an EP11 CPRB is processed for sending to a crypto card. This check is only active on custom device nodes but may lead to access heap memory behind perms->adm when an administrative CPRB is sent. Add correct limit (AP_DOMAINS = 256) checking to fix this.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-80709
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Fix wrong domain value verification with EP11 CPRBs There is a wrong upper limit check for the domain value when an EP11 CPRB is processed for sending to a crypto card. This check is only active on custom device nodes but may lead to access heap memory behind perms->adm when an administrative CPRB is sent. Add correct limit (AP_DOMAINS = 256) checking to fix this.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-80710 - s390/dasd: Fix undersized format-check buffer
CVE ID :CVE-2026-80710
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Fix undersized format-check buffer fmt_buffer_size in dasd_eckd_check_device_format() is declared as int, even though one of the multiplicands, sizeof(struct eckd_count), is a size_t. The expression trkcount * rpt_max * sizeof(struct eckd_count) is therefore correctly evaluated at 64-bit width, but the result is silently truncated when it is stored back into the 32-bit fmt_buffer_size variable. For a sufficiently large track range (start_unit/stop_unit are caller-controlled) this truncation yields a buffer size far smaller than the number of tracks actually requested. kzalloc() then succeeds with an undersized allocation, while the subsequent channel program build still operates on the untruncated track count and writes past the end of that buffer. Compute the buffer size with check_mul_overflow() and keep it in a size_t, so that a value that no longer fits results in -EINVAL instead of a silently truncated allocation size.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-80710
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Fix undersized format-check buffer fmt_buffer_size in dasd_eckd_check_device_format() is declared as int, even though one of the multiplicands, sizeof(struct eckd_count), is a size_t. The expression trkcount * rpt_max * sizeof(struct eckd_count) is therefore correctly evaluated at 64-bit width, but the result is silently truncated when it is stored back into the 32-bit fmt_buffer_size variable. For a sufficiently large track range (start_unit/stop_unit are caller-controlled) this truncation yields a buffer size far smaller than the number of tracks actually requested. kzalloc() then succeeds with an undersized allocation, while the subsequent channel program build still operates on the untruncated track count and writes past the end of that buffer. Compute the buffer size with check_mul_overflow() and keep it in a size_t, so that a value that no longer fits results in -EINVAL instead of a silently truncated allocation size.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-80711 - power: supply: max17040: handle missing status supplier
CVE ID :CVE-2026-80711
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: power: supply: max17040: handle missing status supplier MAX17040 does not report charger state itself, so the driver forwards POWER_SUPPLY_PROP_STATUS to a supplier power supply. If no supplier is registered, power_supply_get_property_from_supplier() returns -ENODEV and leaves the output value untouched. max17040_get_property() currently ignores that error and returns success, so userspace can read an uninitialized status value from the battery power supply. This happens on systems that use the fuel gauge without a charger supplier relationship in firmware. Return POWER_SUPPLY_STATUS_UNKNOWN when no supplier provides STATUS, and propagate other supplier lookup errors.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-80711
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: power: supply: max17040: handle missing status supplier MAX17040 does not report charger state itself, so the driver forwards POWER_SUPPLY_PROP_STATUS to a supplier power supply. If no supplier is registered, power_supply_get_property_from_supplier() returns -ENODEV and leaves the output value untouched. max17040_get_property() currently ignores that error and returns success, so userspace can read an uninitialized status value from the battery power supply. This happens on systems that use the fuel gauge without a charger supplier relationship in firmware. Return POWER_SUPPLY_STATUS_UNKNOWN when no supplier provides STATUS, and propagate other supplier lookup errors.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-80712 - spi: spi-qpic-snand: write the feature value before executing SET_FEATURE
CVE ID :CVE-2026-80712
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: spi: spi-qpic-snand: write the feature value before executing SET_FEATURE qcom_spi_send_cmdaddr() programs NAND_FLASH_CMD/NAND_EXEC_CMD and submits the descriptors, which makes the controller execute the command immediately. For SPINAND_SET_FEATURE the value to be written is only placed into NAND_FLASH_FEATURES afterwards, by qcom_spi_io_op(), in a second submission - so the chip is programmed with whatever that register happened to hold from a previous operation, and the intended value is only applied by the *next* SET_FEATURE. Measured on a TP-Link Archer AX55 v1 (IPQ5018, ESMT F50L1G41LB): writing 0x40 to the configuration register (0xb0) leaves the chip at 0x00, and the subsequent write of 0x00 leaves it at 0x40 - every write lands one operation late. This stayed unnoticed until v6.18 added SPI-NAND OTP support together with OTP entries for ESMT chips. spinand_otp_rw() enables OTP mode, reads, and disables it again, and mtd_otp_nvmem_add() does this during MTD registration. With the off-by-one, the "disable" write actually applies the previously requested value, so CFG_OTP_ENABLE ends up set: the chip stays in OTP mode, every subsequent array read returns the OTP area instead of the array (UBI reports an empty device) and all writes fail with -EIO because the OTP area is write protected. On this board that makes the whole flash unusable and the device unbootable. Write the feature value into NAND_FLASH_FEATURES as part of the same transaction, before NAND_EXEC_CMD. While at it, copy only the bytes the operation actually carries - the previous code dereferenced a 4-byte pointer on a one-byte buffer (spinand->scratchbuf). With this patch the flash contents read back bit-identical to a known-good dump of the same board taken under the vendor firmware (md5-verified across partitions), and writes work.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-80712
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: spi: spi-qpic-snand: write the feature value before executing SET_FEATURE qcom_spi_send_cmdaddr() programs NAND_FLASH_CMD/NAND_EXEC_CMD and submits the descriptors, which makes the controller execute the command immediately. For SPINAND_SET_FEATURE the value to be written is only placed into NAND_FLASH_FEATURES afterwards, by qcom_spi_io_op(), in a second submission - so the chip is programmed with whatever that register happened to hold from a previous operation, and the intended value is only applied by the *next* SET_FEATURE. Measured on a TP-Link Archer AX55 v1 (IPQ5018, ESMT F50L1G41LB): writing 0x40 to the configuration register (0xb0) leaves the chip at 0x00, and the subsequent write of 0x00 leaves it at 0x40 - every write lands one operation late. This stayed unnoticed until v6.18 added SPI-NAND OTP support together with OTP entries for ESMT chips. spinand_otp_rw() enables OTP mode, reads, and disables it again, and mtd_otp_nvmem_add() does this during MTD registration. With the off-by-one, the "disable" write actually applies the previously requested value, so CFG_OTP_ENABLE ends up set: the chip stays in OTP mode, every subsequent array read returns the OTP area instead of the array (UBI reports an empty device) and all writes fail with -EIO because the OTP area is write protected. On this board that makes the whole flash unusable and the device unbootable. Write the feature value into NAND_FLASH_FEATURES as part of the same transaction, before NAND_EXEC_CMD. While at it, copy only the bytes the operation actually carries - the previous code dereferenced a 4-byte pointer on a one-byte buffer (spinand->scratchbuf). With this patch the flash contents read back bit-identical to a known-good dump of the same board taken under the vendor firmware (md5-verified across partitions), and writes work.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-80713 - io_uring: preserve task restrictions across exec
CVE ID :CVE-2026-80713
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: io_uring: preserve task restrictions across exec Per-task restrictions apply to all rings created by a task. Once installed, they should not be dropped across exec. For a task that has used io_uring, the exec cancellation path calls __io_uring_free(). This frees both the task context and the per-task restriction, so a ring created after exec is unrestricted. Split task context cleanup into io_uring_free_tctx(), and use it from the exec cancellation path. Keep __io_uring_free() for final task cleanup, where both the context and restriction are released.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-80713
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: io_uring: preserve task restrictions across exec Per-task restrictions apply to all rings created by a task. Once installed, they should not be dropped across exec. For a task that has used io_uring, the exec cancellation path calls __io_uring_free(). This frees both the task context and the per-task restriction, so a ring created after exec is unrestricted. Split task context cleanup into io_uring_free_tctx(), and use it from the exec cancellation path. Keep __io_uring_free() for final task cleanup, where both the context and restriction are released.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-80714 - ipvs: do not propagate one-packet flag to synced conns
CVE ID :CVE-2026-80714
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: ipvs: do not propagate one-packet flag to synced conns Synced connections can be created before their destination exists. When the destination is later added, ip_vs_bind_dest() copies connection flags from the destination into cp->flags. IP_VS_CONN_F_ONE_PACKET connections are not synced. If a synced connection inherits IP_VS_CONN_F_ONE_PACKET while it is already hashed, expiry can treat it as a one-packet connection and skip unlinking the existing conn_tab node, leaving stale hash nodes pointing at a freed struct ip_vs_conn. Drop IP_VS_CONN_F_ONE_PACKET from destination flags when binding synced connections.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-80714
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: ipvs: do not propagate one-packet flag to synced conns Synced connections can be created before their destination exists. When the destination is later added, ip_vs_bind_dest() copies connection flags from the destination into cp->flags. IP_VS_CONN_F_ONE_PACKET connections are not synced. If a synced connection inherits IP_VS_CONN_F_ONE_PACKET while it is already hashed, expiry can treat it as a one-packet connection and skip unlinking the existing conn_tab node, leaving stale hash nodes pointing at a freed struct ip_vs_conn. Drop IP_VS_CONN_F_ONE_PACKET from destination flags when binding synced connections.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-80715 - igc: remove napi_synchronize() in igc_down()
CVE ID :CVE-2026-80715
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: igc: remove napi_synchronize() in igc_down() When an AF_XDP zero-copy application is killed abruptly, the XSK pool is torn down but NAPI keeps polling. igc_clean_rx_irq_zc() then returns the full budget on every poll, so napi_complete_done() never clears NAPI_STATE_SCHED. igc_down() calls napi_synchronize() before napi_disable(), so it spins forever waiting for that bit and the interface never goes down. Drop the napi_synchronize() and let napi_disable() do the job -- it sets NAPI_STATE_DISABLE, which forces the stuck poll to complete. Reorder it ahead of igc_set_queue_napi() so the NAPI mapping is cleared only after polling has stopped, matching the recent igb fix b1e067240379.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-80715
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: igc: remove napi_synchronize() in igc_down() When an AF_XDP zero-copy application is killed abruptly, the XSK pool is torn down but NAPI keeps polling. igc_clean_rx_irq_zc() then returns the full budget on every poll, so napi_complete_done() never clears NAPI_STATE_SCHED. igc_down() calls napi_synchronize() before napi_disable(), so it spins forever waiting for that bit and the interface never goes down. Drop the napi_synchronize() and let napi_disable() do the job -- it sets NAPI_STATE_DISABLE, which forces the stuck poll to complete. Reorder it ahead of igc_set_queue_napi() so the NAPI mapping is cleared only after polling has stopped, matching the recent igb fix b1e067240379.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-80716 - ALSA: pcm: wake linked drain waiters on unlink
CVE ID :CVE-2026-80716
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: wake linked drain waiters on unlink snd_pcm_drain() on a linked stream parks an on-stack wait entry on the drained peer's runtime->sleep, and after schedule_timeout() removes it only if that peer is still found in the caller's group. If group membership changes during the wait and the sleep ends by signal or timeout (so autoremove_wake_function() does not run), finish_wait() is skipped and snd_pcm_drain() returns with the entry still queued on that stream's sleep list; a later wake_up() then walks a freed stack frame. This is reachable by unlinking either the drained or the draining stream. Unlike the close path (snd_pcm_drop() -> snd_pcm_post_stop()), snd_pcm_unlink() never wakes the sleep queues. Wake every group member under the group lock before the membership change, so a linked drainer is released and drops its entry while the streams are still grouped. The window was opened when snd_pcm_link_rwsem stopped being held across the wait and the removal became conditional on group membership (see Fixes). The later switch to finish_wait() kept that conditional removal, so the signal/timeout case remained.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-80716
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: wake linked drain waiters on unlink snd_pcm_drain() on a linked stream parks an on-stack wait entry on the drained peer's runtime->sleep, and after schedule_timeout() removes it only if that peer is still found in the caller's group. If group membership changes during the wait and the sleep ends by signal or timeout (so autoremove_wake_function() does not run), finish_wait() is skipped and snd_pcm_drain() returns with the entry still queued on that stream's sleep list; a later wake_up() then walks a freed stack frame. This is reachable by unlinking either the drained or the draining stream. Unlike the close path (snd_pcm_drop() -> snd_pcm_post_stop()), snd_pcm_unlink() never wakes the sleep queues. Wake every group member under the group lock before the membership change, so a linked drainer is released and drops its entry while the streams are still grouped. The window was opened when snd_pcm_link_rwsem stopped being held across the wait and the removal became conditional on group membership (see Fixes). The later switch to finish_wait() kept that conditional removal, so the signal/timeout case remained.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-80717 - sctp: validate Adaptation Indication parameter length
CVE ID :CVE-2026-80717
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: sctp: validate Adaptation Indication parameter length The Adaptation Layer Indication parameter contains a fixed 32-bit Adaptation Code Point after its parameter header. However, sctp_verify_param() accepts a header-only parameter because the generic parameter walker only requires the header to be present. sctp_process_param() then reads adaptation_ind beyond the declared parameter. When the malformed parameter is last in an INIT, the read starts at the receive skb tail, and the value is copied into the state cookie returned in the INIT ACK. This may disclose four receive-buffer tail bytes. Require the declared parameter length to match the fixed structure size and abort the association through the existing invalid parameter length path otherwise.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-80717
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: sctp: validate Adaptation Indication parameter length The Adaptation Layer Indication parameter contains a fixed 32-bit Adaptation Code Point after its parameter header. However, sctp_verify_param() accepts a header-only parameter because the generic parameter walker only requires the header to be present. sctp_process_param() then reads adaptation_ind beyond the declared parameter. When the malformed parameter is last in an INIT, the read starts at the receive skb tail, and the value is copied into the state cookie returned in the INIT ACK. This may disclose four receive-buffer tail bytes. Require the declared parameter length to match the fixed structure size and abort the association through the existing invalid parameter length path otherwise.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-80718 - mm/percpu-km: fix bitmap overflow and accounting in pcpu_create_chunk()
CVE ID :CVE-2026-80718
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: mm/percpu-km: fix bitmap overflow and accounting in pcpu_create_chunk() In pcpu_create_chunk(), nr_pages is the total contiguous backing allocation, i.e., nr_units * pcpu_unit_pages, but pcpu_chunk_populated() uses it to set chunk->populated, whose size is pcpu_unit_pages, bitmap. Since bit N in chunk->populated means page offset N inside every unit is backed. When nr_units > 1, the function writes beyond chunk->populated. Fix it by using chunk->nr_pages. It also fixes the global pcpu_nr_empty_pop_pages accounting, since pcpu_balance_free() only iterates up to chunk->nr_pages. Commit a63d4ac4ab609 ("percpu: make percpu-km set chunk->populated bitmap properly") introduced the bitmap overflow issue. Later, commit b539b87fed37f ("percpu: implmeent pcpu_nr_empty_pop_pages and chunk->nr_populated") added pcpu_nr_empty_pop_pages and caused the accounting issue.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-80718
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: mm/percpu-km: fix bitmap overflow and accounting in pcpu_create_chunk() In pcpu_create_chunk(), nr_pages is the total contiguous backing allocation, i.e., nr_units * pcpu_unit_pages, but pcpu_chunk_populated() uses it to set chunk->populated, whose size is pcpu_unit_pages, bitmap. Since bit N in chunk->populated means page offset N inside every unit is backed. When nr_units > 1, the function writes beyond chunk->populated. Fix it by using chunk->nr_pages. It also fixes the global pcpu_nr_empty_pop_pages accounting, since pcpu_balance_free() only iterates up to chunk->nr_pages. Commit a63d4ac4ab609 ("percpu: make percpu-km set chunk->populated bitmap properly") introduced the bitmap overflow issue. Later, commit b539b87fed37f ("percpu: implmeent pcpu_nr_empty_pop_pages and chunk->nr_populated") added pcpu_nr_empty_pop_pages and caused the accounting issue.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-80719 - mm: mglru: fix stale batch updates after memcg reparenting
CVE ID :CVE-2026-80719
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: mm: mglru: fix stale batch updates after memcg reparenting The mglru page table walker batches per-generation size deltas in walk->nr_pages while walking page tables without holding the lruvec lock. The reset_batch_size() later folds those deltas into walk->lruvec under the lruvec lock. The page table walker can run concurrently with the memcg reparenting path as follows: CPU0 CPU1 ==== ==== walk_mm --> walk_page_range --> update_batch_size --> walk->nr_pages += delta mem_cgroup_css_offline --> memcg_reparent_objcgs --> lock lruvec lru_gen_reparent_memcg --> reparent child folios to parent unlock lruvec lock lruvec reset_batch_size --> child lrugen->nr_pages += delta This will trigger the following warning in lru_gen_exit_memcg(): VM_WARN_ON_ONCE(memchr_inv(lruvec->lrugen.nr_pages, 0, sizeof(lruvec->lrugen.nr_pages))); And the user-visible impact of underestimated nr_pages in MGLRU was premature OOMs because MGLRU does not try to reclaim memory when nr_pages reaches zero, but there are still more pages. To fix it, make reset_batch_size() check CSS_DYING under RCU before flushing the pending batch. A non-dying memcg keeps the original lruvec stable against RCU-delayed offlining; a dying memcg redirects the deltas to the first non-dying ancestor.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-80719
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: mm: mglru: fix stale batch updates after memcg reparenting The mglru page table walker batches per-generation size deltas in walk->nr_pages while walking page tables without holding the lruvec lock. The reset_batch_size() later folds those deltas into walk->lruvec under the lruvec lock. The page table walker can run concurrently with the memcg reparenting path as follows: CPU0 CPU1 ==== ==== walk_mm --> walk_page_range --> update_batch_size --> walk->nr_pages += delta mem_cgroup_css_offline --> memcg_reparent_objcgs --> lock lruvec lru_gen_reparent_memcg --> reparent child folios to parent unlock lruvec lock lruvec reset_batch_size --> child lrugen->nr_pages += delta This will trigger the following warning in lru_gen_exit_memcg(): VM_WARN_ON_ONCE(memchr_inv(lruvec->lrugen.nr_pages, 0, sizeof(lruvec->lrugen.nr_pages))); And the user-visible impact of underestimated nr_pages in MGLRU was premature OOMs because MGLRU does not try to reclaim memory when nr_pages reaches zero, but there are still more pages. To fix it, make reset_batch_size() check CSS_DYING under RCU before flushing the pending batch. A non-dying memcg keeps the original lruvec stable against RCU-delayed offlining; a dying memcg redirects the deltas to the first non-dying ancestor.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-80720 - iomap: add a separate bio_set for iomap_split_ioend
CVE ID :CVE-2026-80720
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: iomap: add a separate bio_set for iomap_split_ioend iomap_split_ioend can split bios that already come from iomap_ioend_bioset and thus deadlock when the bioset is exhausted. Add a separate bio_set to avoid this deadlock. Christian Brauner says: Mark iomap_ioend_split_bioset static as it is only used in ioend.c, fixing the sparse warning reported by the kernel test robot.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-80720
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: iomap: add a separate bio_set for iomap_split_ioend iomap_split_ioend can split bios that already come from iomap_ioend_bioset and thus deadlock when the bioset is exhausted. Add a separate bio_set to avoid this deadlock. Christian Brauner says: Mark iomap_ioend_split_bioset static as it is only used in ioend.c, fixing the sparse warning reported by the kernel test robot.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-80721 - Bluetooth: ISO: ensure no dangling hcon references in iso_conn
CVE ID :CVE-2026-80721
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: ensure no dangling hcon references in iso_conn After iso_conn_del(), ISO sockets should not dereference the hcon any more. Currently, clearing iso_conn::hcon relies on iso_conn_del() releasing the last reference to the iso_conn. Simplify this by explicitly clearing conn->hcon in iso_conn_del(), to avoid more complex reasoning on races about who holds the last reference.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-80721
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: ensure no dangling hcon references in iso_conn After iso_conn_del(), ISO sockets should not dereference the hcon any more. Currently, clearing iso_conn::hcon relies on iso_conn_del() releasing the last reference to the iso_conn. Simplify this by explicitly clearing conn->hcon in iso_conn_del(), to avoid more complex reasoning on races about who holds the last reference.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-80722 - wifi: mac80211: validate individual TWT params before driver setup
CVE ID :CVE-2026-80722
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: validate individual TWT params before driver setup ieee80211_process_rx_twt_action() only partially validates a received S1G TWT setup frame before queueing it. An individual agreement can therefore reach ieee80211_s1g_rx_twt_setup() with twt->length too short for the full struct ieee80211_twt_params. The individual path passes twt to drv_add_twt_setup(). Both the tracepoint and the driver callback consume the complete parameters block, not merely req_type. Do not pass a short individual agreement to the driver. Broadcast agreements remain unchanged because they are rejected locally after accessing only req_type. [edit commit message to not overclaim lack of validation nor understate driver impact]
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-80722
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: validate individual TWT params before driver setup ieee80211_process_rx_twt_action() only partially validates a received S1G TWT setup frame before queueing it. An individual agreement can therefore reach ieee80211_s1g_rx_twt_setup() with twt->length too short for the full struct ieee80211_twt_params. The individual path passes twt to drv_add_twt_setup(). Both the tracepoint and the driver callback consume the complete parameters block, not merely req_type. Do not pass a short individual agreement to the driver. Broadcast agreements remain unchanged because they are rejected locally after accessing only req_type. [edit commit message to not overclaim lack of validation nor understate driver impact]
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-80723 - of: reserved_mem: prevent OOB when too many dynamic regions are defined
CVE ID :CVE-2026-80723
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: of: reserved_mem: prevent OOB when too many dynamic regions are defined On boot, fdt_scan_reserved_mem() saves each dynamically-placed /reserved-memory subnode into a local array of size MAX_RESERVED_REGIONS. If the device tree defines more than MAX_RESERVED_REGIONS dynamically-placed regions, fdt_scan_reserved_mem() writes past the end of the local array. Add a bounds check that logs an error and skips the excess regions, restoring the original behavior.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-80723
Published : Aug. 28, 2026, 6:53 a.m. | 58 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: of: reserved_mem: prevent OOB when too many dynamic regions are defined On boot, fdt_scan_reserved_mem() saves each dynamically-placed /reserved-memory subnode into a local array of size MAX_RESERVED_REGIONS. If the device tree defines more than MAX_RESERVED_REGIONS dynamically-placed regions, fdt_scan_reserved_mem() writes past the end of the local array. Add a bounds check that logs an error and skips the excess regions, restoring the original behavior.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-82123 - WordPress Loops & Logic - Reflected XSS
CVE ID :CVE-2026-82123
Published : Aug. 28, 2026, 6:54 a.m. | 56 minutes ago
Description :Improper neutralization of input during web page generation ('cross-site scripting') vulnerability in Tangible Loops & Logic.
Severity: 6.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-82123
Published : Aug. 28, 2026, 6:54 a.m. | 56 minutes ago
Description :Improper neutralization of input during web page generation ('cross-site scripting') vulnerability in Tangible Loops & Logic.
Severity: 6.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-80724 - ptp: vmclock: prevent read-only mappings from becoming writable
CVE ID :CVE-2026-80724
Published : Aug. 28, 2026, 7:03 a.m. | 48 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: ptp: vmclock: prevent read-only mappings from becoming writable vmclock_miscdev_mmap() rejects writable mappings of the shared vmclock ABI page with -EROFS, but leaves VM_MAYWRITE set. Userspace can map the page read-only and then upgrade it to writable with mprotect(), after which the guest can corrupt the host-written timekeeping data (sequence counter, UTC time, TSC offset) that the vmclock ABI defines as read-only. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 does for its read-only objects and as fixed in drm/vc4 (CVE-2026-68445) and drm/panthor (CVE-2024-53071).
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-80724
Published : Aug. 28, 2026, 7:03 a.m. | 48 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: ptp: vmclock: prevent read-only mappings from becoming writable vmclock_miscdev_mmap() rejects writable mappings of the shared vmclock ABI page with -EROFS, but leaves VM_MAYWRITE set. Userspace can map the page read-only and then upgrade it to writable with mprotect(), after which the guest can corrupt the host-written timekeeping data (sequence counter, UTC time, TSC offset) that the vmclock ABI defines as read-only. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 does for its read-only objects and as fixed in drm/vc4 (CVE-2026-68445) and drm/panthor (CVE-2024-53071).
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...