huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2022-48905: kernel: ibmvnic: free reset-work-item when flushing
Component: kernel
Severity: Low
CWE: CWE-401 (Missing Release of Memory after Effective Lifetime)
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: 2024-08-22T00:00:00+00:00

A memory leak flaw was found in the Linux kernel’s IBM Virtual Network Interface Controller (ibmvnic ) driver. This issue involved not properly freeing memory associated with a reset work item when the reset work queue is flushed, causing the reset-work-item not to be deallocated. This flaw allows an attacker with control over the virtual NIC to repeatedly trigger interface resets to cause small amounts of memory to leak. Over time, this can lead to memory exhaustion, especially in systems already resource-constrained or under heavy load, resulting in a possible denial of service (DoS) condition.


Affected upstream versions: 4.18
Fixed upstream versions: 0, 4.19.233, 5.10.104, 5.15.27, 5.16.13, 5.17, 5.4.183
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 786576c03b313a9ff6585458aa0dfd039d897f51
CVE-2022-48912: kernel: netfilter: fix use-after-free in __nf_register_net_hook()
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: 2024-08-22T00:00:00+00:00

A possible use-after-free was found in the Linux kernel in __nf_register_net_hook().

Statement: This issue is fixed in RHEL-9.1 and above (including 8.10):
~~~
in (rhel-8.7, rhel-8.8, rhel-8.9, rhel-8.10) netfilter: fix use-after-free in __nf_register_net_hook()
in (rhel-9.1, rhel-9.2, rhel-9.3, rhel-9.4, rhel-9.5) netfilter: fix use-after-free in __nf_register_net_hook()
~~~

Please note that while RHEL-9 kernel-rt still appears as affected, it has been fixed in the same RHSA as RHEL-9 kernel. This is because from RHEL-9.3 onwards, the kernel and kernel-rt fixes are bundled together in a single errata.

Affected upstream versions: 4.14
Fixed upstream versions: 0, 4.14.270, 4.19.233, 5.10.104, 5.15.27, 5.16.13, 5.17, 5.4.183
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 05f7927b25d2635e87267ff6c79db79fb46cf313
CVE-2022-48915: kernel: thermal: core: Fix TZ_GET_TRIP NULL pointer dereference
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: 2024-08-22T00:00:00+00:00

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

thermal: core: Fix TZ_GET_TRIP NULL pointer dereference

Do not call get_trip_hyst() from thermal_genl_cmd_tz_get_trip() if
the thermal zone does not define one.

Statement: This issue is fixed in RHEL-9.2 and above (including RHEL 8.10)
~~~
in (rhel-8.7, rhel-8.8, rhel-8.9, rhel-8.10) thermal: core: Fix TZ_GET_TRIP NULL pointer dereference
in (rhel-9.2, rhel-9.3, rhel-9.4, rhel-9.5) thermal: core: Fix TZ_GET_TRIP NULL pointer dereference
~~~

Please note that while RHEL-9 kernel-rt still appears as affected, it has been fixed in the same RHSA as RHEL-9 kernel. This is because from RHEL-9.3 onwards, the kernel and kernel-rt fixes are bundled together in a single errata.

Affected upstream versions: 5.9
Fixed upstream versions: 0, 5.10.104, 5.15.27, 5.16.13, 5.17
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 1c0b51e62a50e9291764d022ed44549e65d6ab9c
CVE-2022-48918: kernel: iwlwifi: mvm: check debugfs_dir ptr before use
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: 2024-08-22T00:00:00+00:00

A denial of service vulnerability was found in the Linux kernel. When debugfs is set as off in the kernel command line, iwiwifi's mvm module uses an invalid/unchecked debugfs_dir pointer, resulting in disruption to availability.


Affected upstream versions: 5.12
Fixed upstream versions: 0, 5.15.27, 5.16.13, 5.17
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 7de1ed755e1ace30d97a724bad32452ed86b653b
CVE-2022-48921: kernel: sched/fair: Fix fault in reweight_entity
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 4.7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-08-22T00:00:00+00:00

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

sched/fair: Fix fault in reweight_entity

Syzbot found a GPF in reweight_entity. This has been bisected to
commit 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() access an invalid
sched_task_group")

There is a race between sched_post_fork() and setpriority(PRIO_PGRP)
within a thread group that causes a null-ptr-deref in
reweight_entity() in CFS. The scenario is that the main process spawns
number of new threads, which then call setpriority(PRIO_PGRP, 0, -20),
wait, and exit.  For each of the new threads the copy_process() gets
invoked, which adds the new task_struct and calls sched_post_fork()
for it.

In the above scenario there is a possibility that
setpriority(PRIO_PGRP) and set_one_prio() will be called for a thread
in the group that is just being created by copy_process(), and for
which the sched_post_fork() has not been executed yet. This will
trigger a null pointer dereference in reweight_entity(), as it will
try to access the run queue pointer, which hasn't been set.

Before the mentioned change the cfs_rq pointer for the task  has been
set in sched_fork(), which is called much earlier in copy_process(),
before the new task is added to the thread_group.  Now it is done in
the sched_post_fork(), which is called after that.  To fix the issue
the remove the update_load param from the update_load param() function
and call reweight_task() only if the task flag doesn't have the
TASK_NEW flag set.


Affected upstream versions: 5.10.80 < 5.10.137, 5.15.3 < 5.15.27, 5.14.19 < 5.15, 5.16
Fixed upstream versions: 0, 5.10.137, 5.15, 5.15.27, 5.16.13, 5.17
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 8f317cd888059c59e2fa924bf4b0957cfa53f78e
CVE-2022-48929: kernel: bpf: Fix crash due to out of bounds access into reg2btf_ids.
Component: kernel
Severity: Moderate
CWE: CWE-125 (Out-of-bounds Read)
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: 2024-08-22T00:00:00+00:00

bpf in linux kernel incorrectly managed register types, leading to out of bounds access and possible kernel crashing when bad pointer gets dereferenced.


Affected upstream versions: 5.16.11 < 5.16.12
Fixed upstream versions: 5.16.12
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 8c39925e98d498b9531343066ef82ae39e41adae
CVE-2022-48934: kernel: nfp: flower: Fix a potential leak in nfp_tunnel_add_shared_mac()
Component: kernel
Severity: Moderate
CWE: CWE-401 (Missing Release of Memory after Effective Lifetime)
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: 2024-08-22T00:00:00+00:00

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

nfp: flower: Fix a potential leak in nfp_tunnel_add_shared_mac()

ida_simple_get() returns an id between min (0) and max (NFP_MAX_MAC_INDEX)
inclusive.
So NFP_MAX_MAC_INDEX (0xff) is a valid id.

In order for the error handling path to work correctly, the 'invalid'
value for 'ida_idx' should not be in the 0..NFP_MAX_MAC_INDEX range,
inclusive.

So set it to -1.

Statement: This issue is fixed in RHEL-9.2 and above:
~~~
in (rhel-9.2, rhel-9.3, rhel-9.4, rhel-9.5) nfp: flower: Fix a potential leak in nfp_tunnel_add_shared_mac()
~~~

Please note that while RHEL-9 kernel-rt still appears as affected, it has been fixed in the same RHSA as RHEL-9 kernel. This is because from RHEL-9.3 onwards, the kernel and kernel-rt fixes are bundled together in a single errata.

Affected upstream versions: 5.1
Fixed upstream versions: 0, 5.10.103, 5.15.26, 5.16.12, 5.17, 5.4.182
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 5ad5886f85b6bd893e3ed19013765fb0c243c069
CVE-2022-48939: kernel: bpf: Add schedule points in batch ops
Component: kernel
Severity: Low
CWE: CWE-834 (Excessive Iteration)
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: 2024-08-22T00:00:00+00:00

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

bpf: Add schedule points in batch ops

syzbot reported various soft lockups caused by bpf batch operations.

 INFO: task kworker/1:1:27 blocked for more than 140 seconds.
 INFO: task hung in rcu_barrier

Nothing prevents batch ops to process huge amount of data,
we need to add schedule points in them.

Note that maybe_wait_bpf_programs(map) calls from
generic_map_delete_batch() can be factorized by moving
the call after the loop.

This will be done later in -next tree once we get this fix merged,
unless there is strong opinion doing this optimization sooner.

Statement: This issue is fixed in RHEL-9.2 and above
~~~
in (rhel-9.2, rhel-9.3, rhel-9.4, rhel-9.5) bpf: Add schedule points in batch ops
~~~

Please note that while RHEL-9 kernel-rt still appears as affected, it has been fixed in the same RHSA as RHEL-9 kernel. This is because from RHEL-9.3 onwards, the kernel and kernel-rt fixes are bundled together in a single errata.

Affected upstream versions: 5.6
Fixed upstream versions: 0, 5.10.103, 5.15.26, 5.16.12, 5.17
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 7ef94bfb08fb9e73defafbd5ddef6b5a0e2ee12b
CVE-2022-48942: kernel: hwmon: Handle failure to register sensor with thermal zone correctly
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: 2024-08-22T00:00:00+00:00

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

hwmon: Handle failure to register sensor with thermal zone correctly

If an attempt is made to a sensor with a thermal zone and it fails,
the call to devm_thermal_zone_of_sensor_register() may return -ENODEV.
This may result in crashes similar to the following.

Unable to handle kernel NULL pointer dereference at virtual address 00000000000003cd
...
Internal error: Oops: 96000021 [#1] PREEMPT SMP
...
pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : mutex_lock+0x18/0x60
lr : thermal_zone_device_update+0x40/0x2e0
sp : ffff800014c4fc60
x29: ffff800014c4fc60 x28: ffff365ee3f6e000 x27: ffffdde218426790
x26: ffff365ee3f6e000 x25: 0000000000000000 x24: ffff365ee3f6e000
x23: ffffdde218426870 x22: ffff365ee3f6e000 x21: 00000000000003cd
x20: ffff365ee8bf3308 x19: ffffffffffffffed x18: 0000000000000000
x17: ffffdde21842689c x16: ffffdde1cb7a0b7c x15: 0000000000000040
x14: ffffdde21a4889a0 x13: 0000000000000228 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
x8 : 0000000001120000 x7 : 0000000000000001 x6 : 0000000000000000
x5 : 0068000878e20f07 x4 : 0000000000000000 x3 : 00000000000003cd
x2 : ffff365ee3f6e000 x1 : 0000000000000000 x0 : 00000000000003cd
Call trace:
 mutex_lock+0x18/0x60
 hwmon_notify_event+0xfc/0x110
 0xffffdde1cb7a0a90
 0xffffdde1cb7a0b7c
 irq_thread_fn+0x2c/0xa0
 irq_thread+0x134/0x240
 kthread+0x178/0x190
 ret_from_fork+0x10/0x20
Code: d503201f d503201f d2800001 aa0103e4 (c8e47c02)

Jon Hunter reports that the exact call sequence is:

hwmon_notify_event()
  --> hwmon_thermal_notify()
    --> thermal_zone_device_update()
      --> update_temperature()
        --> mutex_lock()

The hwmon core needs to handle all errors returned from calls
to devm_thermal_zone_of_sensor_register(). If the call fails
with -ENODEV, report that the sensor was not attached to a
thermal zone  but continue to register the hwmon device.

Statement: This issue is fixed in RHEL-9.2 and above:
~~~
in (rhel-9.2, rhel-9.3, rhel-9.4, rhel-9.5) hwmon: Handle failure to register sensor with thermal zone correctly
~~~

Please note that while RHEL-9 kernel-rt still appears as affected, it has been fixed in the same RHSA as RHEL-9 kernel. This is because from RHEL-9.3 onwards, the kernel and kernel-rt fixes are bundled together in a single errata.

Affected upstream versions: 5.8
Fixed upstream versions: 0, 5.10.103, 5.15.26, 5.16.12, 5.17
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 962b2a3188bfa5388756ffbc47dfa5ff59cb8011
CVE-2022-48943: kernel: KVM: x86/mmu: make apf token non-zero to fix bug
Component: kernel
Severity: Moderate
CWE: CWE-367 (Time-of-check Time-of-use (TOCTOU) Race Condition)
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: 2024-08-22T00:00:00+00:00

A hang vulnerability is possible in the Linux kernel in arch/x86/kvm/mmu/mmu.c. This issue may lead to compromised availability.

Statement: This issue is fixed in RHEL-9.0 and above (including 8.10):
~~~
in (rhel-9.1, rhel-9.2, rhel-9.3, rhel-9.4, rhel-9.5) KVM: x86/mmu: make apf token non-zero to fix bug
in (rhel-8.7, rhel-8.8, rhel-8.9, rhel-8.10) KVM: x86/mmu: make apf token non-zero to fix bug
in (rhel-9.0) KVM: x86/mmu: make apf token non-zero to fix bug
in (rhel-8.6) KVM: x86/mmu: make apf token non-zero to fix bug
~~~

Please note that while RHEL-9 kernel-rt still appears as affected, it has been fixed in the same RHSA as RHEL-9 kernel. This is because from RHEL-9.3 onwards, the kernel and kernel-rt fixes are bundled together in a single errata.

Affected upstream versions: 5.8
Fixed upstream versions: 0, 5.10.103, 5.15.26, 5.16.12, 5.17
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 72fdfc75d4217b32363cc80def3de2cb3fef3f02
CVE-2022-48947: kernel: Bluetooth: L2CAP: Fix u8 overflow
Component: kernel
Severity: Moderate
CWE: CWE-190 (Integer Overflow or Wraparound)
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: 2024-10-21T00:00:00+00:00

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

Bluetooth: L2CAP: Fix u8 overflow

By keep sending L2CAP_CONF_REQ packets, chan->num_conf_rsp increases
multiple times and eventually it will wrap around the maximum number
(i.e., 255).
This patch prevents this by adding a boundary check with
L2CAP_MAX_CONF_RSP

Btmon log:
Bluetooth monitor ver 5.64
= Note: Linux version 6.1.0-rc2 (x86_64)                               0.264594
= Note: Bluetooth subsystem version 2.22                               0.264636
@ MGMT Open: btmon (privileged) version 1.22                  {0x0001} 0.272191
= New Index: 00:00:00:00:00:00 (Primary,Virtual,hci0)          [hci0] 13.877604
@ RAW Open: 9496 (privileged) version 2.22                   {0x0002} 13.890741
= Open Index: 00:00:00:00:00:00                                [hci0] 13.900426
(...)
> ACL Data RX: Handle 200 flags 0x00 dlen 1033             #32 [hci0] 14.273106
        invalid packet size (12 != 1033)
        08 00 01 00 02 01 04 00 01 10 ff ff              ............
> ACL Data RX: Handle 200 flags 0x00 dlen 1547             #33 [hci0] 14.273561
        invalid packet size (14 != 1547)
        0a 00 01 00 04 01 06 00 40 00 00 00 00 00        ........@.....
> ACL Data RX: Handle 200 flags 0x00 dlen 2061             #34 [hci0] 14.274390
        invalid packet size (16 != 2061)
        0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04  ........@.......
> ACL Data RX: Handle 200 flags 0x00 dlen 2061             #35 [hci0] 14.274932
        invalid packet size (16 != 2061)
        0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00  ........@.......
= bluetoothd: Bluetooth daemon 5.43                                   14.401828
> ACL Data RX: Handle 200 flags 0x00 dlen 1033             #36 [hci0] 14.275753
        invalid packet size (12 != 1033)
        08 00 01 00 04 01 04 00 40 00 00 00              ........@...

Statement: This issue is fixed in RHEL-9.4 and above (including RHEL 8.10)
~~~
ceae2a8af1e2 (in rhel-9.4, rhel-9.5, rhel-9.6) Bluetooth: L2CAP: Fix u8 overflow
371b9a14a101 (in rhel-8.10) Bluetooth: L2CAP: Fix u8 overflow
~~~

Please note that while RHEL-9 kernel-rt still appears as affected, it has been fixed in the same RHSA as RHEL-9 kernel. This is because from RHEL-9.3 onwards, the kernel and kernel-rt fixes are bundled together in a single errata.

Affected upstream versions: 2.6.32
Fixed upstream versions: 0, 4.14.303, 4.19.270, 4.9.337, 5.10.161, 5.15.85, 5.4.229, 6.0.15, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 49d5867819ab7c744852b45509e8469839c07e0e
CVE-2022-48969: kernel: xen-netfront: Fix NULL sring after live migration
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: 2024-10-21T00:00:00+00:00

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

xen-netfront: Fix NULL sring after live migration

A NAPI is setup for each network sring to poll data to kernel
The sring with source host is destroyed before live migration and
new sring with target host is setup after live migration.
The NAPI for the old sring is not deleted until setup new sring
with target host after migration. With busy_poll/busy_read enabled,
the NAPI can be polled before got deleted when resume VM.

BUG: unable to handle kernel NULL pointer dereference at
0000000000000008
IP: xennet_poll+0xae/0xd20
PGD 0 P4D 0
Oops: 0000 [#1] SMP PTI
Call Trace:
 finish_task_switch+0x71/0x230
 timerqueue_del+0x1d/0x40
 hrtimer_try_to_cancel+0xb5/0x110
 xennet_alloc_rx_buffers+0x2a0/0x2a0
 napi_busy_loop+0xdb/0x270
 sock_poll+0x87/0x90
 do_sys_poll+0x26f/0x580
 tracing_map_insert+0x1d4/0x2f0
 event_hist_trigger+0x14a/0x260

 finish_task_switch+0x71/0x230
 __schedule+0x256/0x890
 recalc_sigpending+0x1b/0x50
 xen_sched_clock+0x15/0x20
 __rb_reserve_next+0x12d/0x140
 ring_buffer_lock_reserve+0x123/0x3d0
 event_triggers_call+0x87/0xb0
 trace_event_buffer_commit+0x1c4/0x210
 xen_clocksource_get_cycles+0x15/0x20
 ktime_get_ts64+0x51/0xf0
 SyS_ppoll+0x160/0x1a0
 SyS_ppoll+0x160/0x1a0
 do_syscall_64+0x73/0x130
 entry_SYSCALL_64_after_hwframe+0x41/0xa6
...
RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900
CR2: 0000000000000008
---[ end trace f8601785b354351c ]---

xen frontend should remove the NAPIs for the old srings before live
migration as the bond srings are destroyed

There is a tiny window between the srings are set to NULL and
the NAPIs are disabled, It is safe as the NAPI threads are still
frozen at that time


Affected upstream versions: 2.6.24
Fixed upstream versions: 0, 4.19.269, 5.10.159, 5.15.83, 5.4.227, 6.0.13, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 99859947517e446058ad7243ee81d2f9801fa3dd
CVE-2022-48974: kernel: netfilter: conntrack: fix using __this_cpu_add in preemptible
Component: kernel
Severity: Moderate
CWE: CWE-99 (Improper Control of Resource Identifiers ('Resource Injection'))
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: 2024-10-21T00:00:00+00:00

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

netfilter: conntrack: fix using __this_cpu_add in preemptible

Currently in nf_conntrack_hash_check_insert(), when it fails in
nf_ct_ext_valid_pre/post(), NF_CT_STAT_INC() will be called in the
preemptible context, a call trace can be triggered:

   BUG: using __this_cpu_add() in preemptible [00000000] code: conntrack/1636
   caller is nf_conntrack_hash_check_insert+0x45/0x430 [nf_conntrack]
   Call Trace:
    <TASK>
    dump_stack_lvl+0x33/0x46
    check_preemption_disabled+0xc3/0xf0
    nf_conntrack_hash_check_insert+0x45/0x430 [nf_conntrack]
    ctnetlink_create_conntrack+0x3cd/0x4e0 [nf_conntrack_netlink]
    ctnetlink_new_conntrack+0x1c0/0x450 [nf_conntrack_netlink]
    nfnetlink_rcv_msg+0x277/0x2f0 [nfnetlink]
    netlink_rcv_skb+0x50/0x100
    nfnetlink_rcv+0x65/0x144 [nfnetlink]
    netlink_unicast+0x1ae/0x290
    netlink_sendmsg+0x257/0x4f0
    sock_sendmsg+0x5f/0x70

This patch is to fix it by changing to use NF_CT_STAT_INC_ATOMIC() for
nf_ct_ext_valid_pre/post() check in nf_conntrack_hash_check_insert(),
as well as nf_ct_ext_valid_post() in __nf_conntrack_confirm().

Note that nf_ct_ext_valid_pre() check in __nf_conntrack_confirm() is
safe to use NF_CT_STAT_INC(), as it's under local_bh_disable().

Statement: This issue is fixed in RHEL-9.2 and above
~~~
in (rhel-9.2, rhel-9.3, rhel-9.4, rhel-9.5, rhel-9.6) netfilter: conntrack: fix using __this_cpu_add in preemptible
~~~

Please note that while RHEL-9 kernel-rt still appears as affected, it has been fixed in the same RHSA as RHEL-9 kernel. This is because from RHEL-9.3 onwards, the kernel and kernel-rt fixes are bundled together in a single errata.

Affected upstream versions: 5.19
Fixed upstream versions: 0, 6.0.13, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: d9bf1138a5db419db13bd9fcd3a7178d6bb20f7c
CVE-2022-48976: kernel: netfilter: flowtable_offload: fix using __this_cpu_add in preemptible
Component: kernel
Severity: Moderate
CWE: CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
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: 2024-10-21T00:00:00+00:00

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

netfilter: flowtable_offload: fix using __this_cpu_add in preemptible

flow_offload_queue_work() can be called in workqueue without
bh disabled, like the call trace showed in my act_ct testing,
calling NF_FLOW_TABLE_STAT_INC() there would cause a call
trace:

  BUG: using __this_cpu_add() in preemptible [00000000] code: kworker/u4:0/138560
  caller is flow_offload_queue_work+0xec/0x1b0 [nf_flow_table]
  Workqueue: act_ct_workqueue tcf_ct_flow_table_cleanup_work [act_ct]
  Call Trace:
   <TASK>
   dump_stack_lvl+0x33/0x46
   check_preemption_disabled+0xc3/0xf0
   flow_offload_queue_work+0xec/0x1b0 [nf_flow_table]
   nf_flow_table_iterate+0x138/0x170 [nf_flow_table]
   nf_flow_table_free+0x140/0x1a0 [nf_flow_table]
   tcf_ct_flow_table_cleanup_work+0x2f/0x2b0 [act_ct]
   process_one_work+0x6a3/0x1030
   worker_thread+0x8a/0xdf0

This patch fixes it by using NF_FLOW_TABLE_STAT_INC_ATOMIC()
instead in flow_offload_queue_work().

Note that for FLOW_CLS_REPLACE branch in flow_offload_queue_work(),
it may not be called in preemptible path, but it's good to use
NF_FLOW_TABLE_STAT_INC_ATOMIC() for all cases in
flow_offload_queue_work().

Statement: This issue is fixed in RHEL-9.2 and above:
~~~
in (rhel-9.2, rhel-9.3, rhel-9.4, rhel-9.5, rhel-9.6) netfilter: flowtable_offload: fix using __this_cpu_add in preemptible
~~~

Please note that while RHEL-9 kernel-rt still appears as affected, it has been fixed in the same RHSA as RHEL-9 kernel. This is because from RHEL-9.3 onwards, the kernel and kernel-rt fixes are bundled together in a single errata.

Affected upstream versions: 5.15.157 < 5.16, 6.0
Fixed upstream versions: 0, 5.16, 6.0.13, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: a220a11fda012fba506b35929672374c2723ae6d