Skip to content

Tags: ctrliq/kernel-src-tree

Tags

resf_kernel-5.14.0-687.20.1.el9_8

Toggle resf_kernel-5.14.0-687.20.1.el9_8's commit message
Tag end of Tag end of resf_kernel-5.14.0-687.20.1.el9_8 - Original Na…

…me: kernel-5.14.0-687.20.1.el9_8

resf_kernel-4.18.0-553.139.1.el8_10

Toggle resf_kernel-4.18.0-553.139.1.el8_10's commit message
Tag end of Tag end of resf_kernel-4.18.0-553.139.1.el8_10 - Original …

…Name: kernel-4.18.0-553.139.1.el8_10

ciq_kernel-5.14.0-570.60.1+16.1.el9_6_ciq

Toggle ciq_kernel-5.14.0-570.60.1+16.1.el9_6_ciq's commit message
net/sched: fix pedit partial COW leading to page cache corruption

jira VULN-188482
cve CVE-2026-46331
commit-author Rajat Gupta <rajat.gupta@oss.qualcomm.com>
commit 899ee91
upstream-diff |
	The upstream commit includes <linux/unaligned.h> for the
	get_unaligned()/put_unaligned() helpers it introduces. That header
	does not exist in this tree; it was created by upstream commit
	5f60d5f ("move asm/unaligned.h to linux/unaligned.h")
	in v6.12, which postdates 5.14. The include is therefore changed to
	<asm/unaligned.h>, which provides the same helpers in this tree.
	No functional change.

tcf_pedit_act() computes the COW range for skb_ensure_writable()
once before the key loop using tcfp_off_max_hint, but the hint does
not account for the runtime header offset added by typed keys. This
can leave part of the write region un-COW'd.

Fix by moving skb_ensure_writable() inside the per-key loop where
the actual write offset is known, and add overflow checking on the
offset arithmetic. For negative offsets (e.g. Ethernet header edits
at ingress), use skb_cow() to COW the headroom instead. Guard
offset_valid() against INT_MIN, where negation is undefined.

Fixes: 8b79647 ("net/sched: act_pedit: really ensure the skb is writable")
	Reported-by: Yiming Qian <yimingqian591@gmail.com>
	Reported-by: Keenan Dong <keenanat2000@gmail.com>
	Reported-by: Han Guidong <2045gemini@gmail.com>
	Reported-by: Zhang Cen <rollkingzzc@gmail.com>
	Reviewed-by: Han Guidong <2045gemini@gmail.com>
	Tested-by: Han Guidong <2045gemini@gmail.com>
	Reviewed-by: Davide Caratti <dcaratti@redhat.com>
	Tested-by: Davide Caratti <dcaratti@redhat.com>
	Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>
	Tested-by: Toke Høiland-Jørgensen <toke@redhat.com>
	Reviewed-by: Victor Nogueira <victor@mojatatu.com>
	Tested-by: Victor Nogueira <victor@mojatatu.com>
	Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
	Signed-off-by: Rajat Gupta <rajat.gupta@oss.qualcomm.com>
Link: https://patch.msgid.link/20260531123221.48732-1-jhs@mojatatu.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 899ee91)
	Signed-off-by: Brett Mastbergen <bmastbergen@ciq.com>

ciq_kernel-5.14.0-284.30.1+33.1.el9_2_ciq

Toggle ciq_kernel-5.14.0-284.30.1+33.1.el9_2_ciq's commit message
mlxsw: spectrum_acl_tcam: Fix memory leak when canceling rehash work

jira VULN-43023
cve CVE-2024-35852
commit-author Ido Schimmel <idosch@nvidia.com>
commit fb4e2b7

The rehash delayed work is rescheduled with a delay if the number of
credits at end of the work is not negative as supposedly it means that
the migration ended. Otherwise, it is rescheduled immediately.

After "mlxsw: spectrum_acl_tcam: Fix possible use-after-free during
rehash" the above is no longer accurate as a non-negative number of
credits is no longer indicative of the migration being done. It can also
happen if the work encountered an error in which case the migration will
resume the next time the work is scheduled.

The significance of the above is that it is possible for the work to be
pending and associated with hints that were allocated when the migration
started. This leads to the hints being leaked [1] when the work is
canceled while pending as part of ACL region dismantle.

Fix by freeing the hints if hints are associated with a work that was
canceled while pending.

Blame the original commit since the reliance on not having a pending
work associated with hints is fragile.

[1]
unreferenced object 0xffff88810e7c3000 (size 256):
  comm "kworker/0:16", pid 176, jiffies 4295460353
  hex dump (first 32 bytes):
    00 30 95 11 81 88 ff ff 61 00 00 00 00 00 00 80  .0......a.......
    00 00 61 00 40 00 00 00 00 00 00 00 04 00 00 00  ..a.@...........
  backtrace (crc 2544ddb9):
    [<00000000cf8cfab3>] kmalloc_trace+0x23f/0x2a0
    [<000000004d9a1ad9>] objagg_hints_get+0x42/0x390
    [<000000000b143cf3>] mlxsw_sp_acl_erp_rehash_hints_get+0xca/0x400
    [<0000000059bdb60a>] mlxsw_sp_acl_tcam_vregion_rehash_work+0x868/0x1160
    [<00000000e81fd734>] process_one_work+0x59c/0xf20
    [<00000000ceee9e81>] worker_thread+0x799/0x12c0
    [<00000000bda6fe39>] kthread+0x246/0x300
    [<0000000070056d23>] ret_from_fork+0x34/0x70
    [<00000000dea2b93e>] ret_from_fork_asm+0x1a/0x30

Fixes: c9c9af9 ("mlxsw: spectrum_acl: Allow to interrupt/continue rehash work")
	Signed-off-by: Ido Schimmel <idosch@nvidia.com>
	Tested-by: Alexander Zubkov <green@qrator.net>
	Signed-off-by: Petr Machata <petrm@nvidia.com>
	Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://lore.kernel.org/r/0cc12ebb07c4d4c41a1265ee2c28b392ff997a86.1713797103.git.petrm@nvidia.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit fb4e2b7)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>