huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2022-50178: kernel: wifi: rtw89: 8852a: rfk: fix div 0 exception
Component: kernel
Severity: Moderate
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

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

wifi: rtw89: 8852a: rfk: fix div 0 exception

The DPK is a kind of RF calibration whose algorithm is to fine tune
parameters and calibrate, and check the result. If the result isn't good
enough, it could adjust parameters and try again.

This issue is to read and show the result, but it could be a negative
calibration result that causes divisor 0 and core dump. So, fix it by
phy_div() that does division only if divisor isn't zero; otherwise,
zero is adopted.

  divide error: 0000 [#1] PREEMPT SMP NOPTI
  CPU: 1 PID: 728 Comm: wpa_supplicant Not tainted 5.10.114-16019-g462a1661811a #1 <HASH:d024 28>
  RIP: 0010:rtw8852a_dpk+0x14ae/0x288f [rtw89_core]
  RSP: 0018:ffffa9bb412a7520 EFLAGS: 00010246
  RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
  RDX: 0000000000000000 RSI: 00000000000180fc RDI: ffffa141d01023c0
  RBP: ffffa9bb412a76a0 R08: 0000000000001319 R09: 00000000ffffff92
  R10: ffffffffc0292de3 R11: ffffffffc00d2f51 R12: 0000000000000000
  R13: ffffa141d01023c0 R14: ffffffffc0290250 R15: ffffa141d0102638
  FS:  00007fa99f5c2740(0000) GS:ffffa142e5e80000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000013e8e010 CR3: 0000000110d2c000 CR4: 0000000000750ee0
  PKRU: 55555554
  Call Trace:
   rtw89_core_sta_add+0x95/0x9c [rtw89_core <HASH:d239 29>]
   rtw89_ops_sta_state+0x5d/0x108 [rtw89_core <HASH:d239 29>]
   drv_sta_state+0x115/0x66f [mac80211 <HASH:81fe 30>]
   sta_info_insert_rcu+0x45c/0x713 [mac80211 <HASH:81fe 30>]
   sta_info_insert+0xf/0x1b [mac80211 <HASH:81fe 30>]
   ieee80211_prep_connection+0x9d6/0xb0c [mac80211 <HASH:81fe 30>]
   ieee80211_mgd_auth+0x2aa/0x352 [mac80211 <HASH:81fe 30>]
   cfg80211_mlme_auth+0x160/0x1f6 [cfg80211 <HASH:00cd 31>]
   nl80211_authenticate+0x2e5/0x306 [cfg80211 <HASH:00cd 31>]
   genl_rcv_msg+0x371/0x3a1
   ? nl80211_stop_sched_scan+0xe5/0xe5 [cfg80211 <HASH:00cd 31>]
   ? genl_rcv+0x36/0x36
   netlink_rcv_skb+0x8a/0xf9
   genl_rcv+0x28/0x36
   netlink_unicast+0x27b/0x3a0
   netlink_sendmsg+0x2aa/0x469
   sock_sendmsg_nosec+0x49/0x4d
   ____sys_sendmsg+0xe5/0x213
   __sys_sendmsg+0xec/0x157
   ? syscall_enter_from_user_mode+0xd7/0x116
   do_syscall_64+0x43/0x55
   entry_SYSCALL_64_after_hwframe+0x44/0xa9
  RIP: 0033:0x7fa99f6e689b


Affected upstream versions: 5.16
Fixed upstream versions: 0, 5.18.18, 5.19.2, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 065e83ac83c0c0e615b96947145c85c4bd76c09a
CVE-2022-50179: kernel: ath9k: fix use-after-free in ath9k_hif_usb_rx_cb
Component: kernel
Severity: Moderate
CWE: CWE-763 (Release of Invalid Pointer or Reference)
CVSS v3: 5.2 (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:H)
Public date: 2025-06-18T00:00:00+00:00

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

ath9k: fix use-after-free in ath9k_hif_usb_rx_cb

Syzbot reported use-after-free Read in ath9k_hif_usb_rx_cb() [0]. The
problem was in incorrect htc_handle->drv_priv initialization.

Probable call trace which can trigger use-after-free:

ath9k_htc_probe_device()
  /* htc_handle->drv_priv = priv; */
  ath9k_htc_wait_for_target()      <--- Failed
  ieee80211_free_hw()		   <--- priv pointer is freed

<IRQ>
...
ath9k_hif_usb_rx_cb()
  ath9k_hif_usb_rx_stream()
   RX_STAT_INC()		<--- htc_handle->drv_priv access

In order to not add fancy protection for drv_priv we can move
htc_handle->drv_priv initialization at the end of the
ath9k_htc_probe_device() and add helper macro to make
all *_STAT_* macros NULL safe, since syzbot has reported related NULL
deref in that macros [1]


Affected upstream versions: 2.6.35
Fixed upstream versions: 0, 4.14.291, 4.19.256, 5.10.137, 5.15.61, 5.18.18, 5.19.2, 5.4.211, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 62bc1ea5c7401d77eaf73d0c6a15f3d2e742856e
CVE-2022-50181: kernel: virtio-gpu: fix a missing check to avoid NULL dereference
Component: kernel
Severity: Moderate
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

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

virtio-gpu: fix a missing check to avoid NULL dereference

'cache_ent' could be set NULL inside virtio_gpu_cmd_get_capset()
and it will lead to a NULL dereference by a lately use of it
(i.e., ptr = cache_ent->caps_cache). Fix it with a NULL check.


[ kraxel: minor codestyle fixup ]


Affected upstream versions: 4.4
Fixed upstream versions: 0, 5.10.137, 5.15.61, 5.18.18, 5.19.2, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 259773fc874258606c0121767a4a27466ff337eb
CVE-2022-50185: kernel: drm/radeon: fix potential buffer overflow in ni_set_mc_special_registers()
Component: kernel
Severity: Moderate
CWE: CWE-787 (Out-of-bounds Write)
CVSS v3: 6.3 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

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

drm/radeon: fix potential buffer overflow in ni_set_mc_special_registers()

The last case label can write two buffers 'mc_reg_address[j]' and
'mc_data[j]' with 'j' offset equal to SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE
since there are no checks for this value in both case labels after the
last 'j++'.

Instead of changing '>' to '>=' there, add the bounds check at the start
of the second 'case' (the first one already has it).

Also, remove redundant last checks for 'j' index bigger than array size.
The expression is always false. Moreover, before or after the patch
'table->last' can be equal to SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE and it
seems it can be a valid value.

Detected using the static analysis tool - Svace.


Affected upstream versions: 3.11
Fixed upstream versions: 0, 4.14.291, 4.19.256, 5.10.137, 5.15.61, 5.18.18, 5.19.2, 5.4.211, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: ea73869df6ef386fc0feeb28ff66742ca835b18f
CVE-2022-50187: kernel: ath11k: fix netdev open race
Component: kernel
Severity: Moderate
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

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

ath11k: fix netdev open race

Make sure to allocate resources needed before registering the device.

This specifically avoids having a racing open() trigger a BUG_ON() in
mod_timer() when ath11k_mac_op_start() is called before the
mon_reap_timer as been set up.

I did not see this issue with next-20220310, but I hit it on every probe
with next-20220511. Perhaps some timing changed in between.

Here's the backtrace:

[   51.346947] kernel BUG at kernel/time/timer.c:990!
[   51.346958] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
...
[   51.578225] Call trace:
[   51.583293]  __mod_timer+0x298/0x390
[   51.589518]  mod_timer+0x14/0x20
[   51.595368]  ath11k_mac_op_start+0x41c/0x4a0 [ath11k]
[   51.603165]  drv_start+0x38/0x60 [mac80211]
[   51.610110]  ieee80211_do_open+0x29c/0x7d0 [mac80211]
[   51.617945]  ieee80211_open+0x60/0xb0 [mac80211]
[   51.625311]  __dev_open+0x100/0x1c0
[   51.631420]  __dev_change_flags+0x194/0x210
[   51.638214]  dev_change_flags+0x24/0x70
[   51.644646]  do_setlink+0x228/0xdb0
[   51.650723]  __rtnl_newlink+0x460/0x830
[   51.657162]  rtnl_newlink+0x4c/0x80
[   51.663229]  rtnetlink_rcv_msg+0x124/0x390
[   51.669917]  netlink_rcv_skb+0x58/0x130
[   51.676314]  rtnetlink_rcv+0x18/0x30
[   51.682460]  netlink_unicast+0x250/0x310
[   51.688960]  netlink_sendmsg+0x19c/0x3e0
[   51.695458]  ____sys_sendmsg+0x220/0x290
[   51.701938]  ___sys_sendmsg+0x7c/0xc0
[   51.708148]  __sys_sendmsg+0x68/0xd0
[   51.714254]  __arm64_sys_sendmsg+0x28/0x40
[   51.720900]  invoke_syscall+0x48/0x120

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3


Affected upstream versions: 5.6
Fixed upstream versions: 0, 5.10.137, 5.15.61, 5.18.18, 5.19.2, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: a2c45f8c3d18269e641f0c7da2dde47ef8414034
CVE-2022-50189: kernel: tools/power turbostat: Fix file pointer leak
Component: kernel
Severity: Low
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: 2025-06-18T00:00:00+00:00

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

tools/power turbostat: Fix file pointer leak

Currently if a fscanf fails then an early return leaks an open
file pointer. Fix this by fclosing the file before the return.
Detected using static analysis with cppcheck:

tools/power/x86/turbostat/turbostat.c:2039:3: error: Resource leak: fp [resourceLeak]


Affected upstream versions: 5.19
Fixed upstream versions: 0, 5.19.2, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 2ebf6f5946817f33fb33e613e359229e98164eb3
CVE-2022-50190: kernel: spi: Fix simplification of devm_spi_register_controller
Component: kernel
Severity: Moderate
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

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

spi: Fix simplification of devm_spi_register_controller

This reverts commit 59ebbe40fb51 ("spi: simplify
devm_spi_register_controller").

If devm_add_action() fails in devm_add_action_or_reset(),
devm_spi_unregister() will be called, it decreases the
refcount of 'ctlr->dev' to 0, then it will cause uaf in
the drivers that calling spi_put_controller() in error path.


Affected upstream versions: 5.13
Fixed upstream versions: 0, 5.15.61, 5.18.18, 5.19.2, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 445fb9c19cf45bd9472fd9babaa31c5e6c7d2720
CVE-2022-50194: kernel: soc: qcom: aoss: Fix refcount leak in qmp_cooling_devices_register
Component: kernel
Severity: Low
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: 2025-06-18T00:00:00+00:00

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

soc: qcom: aoss: Fix refcount leak in qmp_cooling_devices_register

Every iteration of for_each_available_child_of_node() decrements
the reference count of the previous node.
When breaking early from a for_each_available_child_of_node() loop,
we need to explicitly call of_node_put() on the child node.
Add missing of_node_put() to avoid refcount leak.


Affected upstream versions: 5.4
Fixed upstream versions: 0, 5.10.137, 5.15.61, 5.18.18, 5.19.2, 5.4.211, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: bc73c72a856c26df7410ddf15f42257cb4960fe9
CVE-2022-50196: kernel: soc: qcom: ocmem: Fix refcount leak in of_get_ocmem
Component: kernel
Severity: Low
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: 2025-06-18T00:00:00+00:00

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

soc: qcom: ocmem: Fix refcount leak in of_get_ocmem

of_parse_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak.
of_node_put() will check NULL pointer.


Affected upstream versions: 5.5
Fixed upstream versions: 0, 5.10.137, 5.15.61, 5.18.18, 5.19.2, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 07aea6819d569d1e172227486655e4fb5bd4cdb9
CVE-2022-50200: kernel: selinux: Add boundary check in put_entry()
Component: kernel
Severity: Moderate
CWE: CWE-125 (Out-of-bounds Read)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

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

selinux: Add boundary check in put_entry()

Just like next_entry(), boundary check is necessary to prevent memory
out-of-bound access.


Affected upstream versions: 2.6.37
Fixed upstream versions: 0, 4.14.291, 4.19.256, 5.10.137, 5.15.61, 5.18.18, 5.19.2, 5.4.211, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 2dabe6a872a5744865372eb30ea51e8ccd21305a
CVE-2022-50202: kernel: PM: hibernate: defer device probing when resuming from hibernation
Component: kernel
Severity: Moderate
CWE: CWE-833 (Deadlock)
CVSS v3: 4.7 (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:H)
Public date: 2025-06-18T00:00:00+00:00

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

PM: hibernate: defer device probing when resuming from hibernation

syzbot is reporting hung task at misc_open() [1], for there is a race
window of AB-BA deadlock which involves probe_count variable. Currently
wait_for_device_probe() from snapshot_open() from misc_open() can sleep
forever with misc_mtx held if probe_count cannot become 0.

When a device is probed by hub_event() work function, probe_count is
incremented before the probe function starts, and probe_count is
decremented after the probe function completed.

There are three cases that can prevent probe_count from dropping to 0.

  (a) A device being probed stopped responding (i.e. broken/malicious
      hardware).

  (b) A process emulating a USB device using /dev/raw-gadget interface
      stopped responding for some reason.

  (c) New device probe requests keeps coming in before existing device
      probe requests complete.

The phenomenon syzbot is reporting is (b). A process which is holding
system_transition_mutex and misc_mtx is waiting for probe_count to become
0 inside wait_for_device_probe(), but the probe function which is called
 from hub_event() work function is waiting for the processes which are
blocked at mutex_lock(&misc_mtx) to respond via /dev/raw-gadget interface.

This patch mitigates (b) by deferring wait_for_device_probe() from
snapshot_open() to snapshot_write() and snapshot_ioctl(). Please note that
the possibility of (b) remains as long as any thread which is emulating a
USB device via /dev/raw-gadget interface can be blocked by uninterruptible
blocking operations (e.g. mutex_lock()).

Please also note that (a) and (c) are not addressed. Regarding (c), we
should change the code to wait for only one device which contains the
image for resuming from hibernation. I don't know how to address (a), for
use of timeout for wait_for_device_probe() might result in loss of user
data in the image. Maybe we should require the userland to wait for the
image device before opening /dev/snapshot interface.


Affected upstream versions: 2.6.30
Fixed upstream versions: 0, 4.14.291, 4.19.256, 5.10.137, 5.15.61, 5.18.18, 5.19.2, 5.4.211, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 8c90947e5f1801e6c7120021c6ea0f3ad6a4eb91
CVE-2022-50206: kernel: arm64: fix oops in concurrently setting insn_emulation sysctls
Component: kernel
Severity: Moderate
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

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

arm64: fix oops in concurrently setting insn_emulation sysctls

emulation_proc_handler() changes table->data for proc_dointvec_minmax
and can generate the following Oops if called concurrently with itself:

 | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
 | Internal error: Oops: 96000006 [#1] SMP
 | Call trace:
 | update_insn_emulation_mode+0xc0/0x148
 | emulation_proc_handler+0x64/0xb8
 | proc_sys_call_handler+0x9c/0xf8
 | proc_sys_write+0x18/0x20
 | __vfs_write+0x20/0x48
 | vfs_write+0xe4/0x1d0
 | ksys_write+0x70/0xf8
 | __arm64_sys_write+0x20/0x28
 | el0_svc_common.constprop.0+0x7c/0x1c0
 | el0_svc_handler+0x2c/0xa0
 | el0_svc+0x8/0x200

To fix this issue, keep the table->data as &insn->current_mode and
use container_of() to retrieve the insn pointer. Another mutex is
used to protect against the current_mode update but not for retrieving
insn_emulation as table->data is no longer changing.


Affected upstream versions: 3.7
Fixed upstream versions: 0, 4.14.291, 4.19.256, 5.10.137, 5.15.61, 5.18.18, 5.19.2, 5.4.211, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 9d5fec6ba2e4117d196a8259ab54615ffe562460
CVE-2022-50212: kernel: netfilter: nf_tables: do not allow CHAIN_ID to refer to another table
Component: kernel
Severity: Moderate
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

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

netfilter: nf_tables: do not allow CHAIN_ID to refer to another table

When doing lookups for chains on the same batch by using its ID, a chain
from a different table can be used. If a rule is added to a table but
refers to a chain in a different table, it will be linked to the chain in
table2, but would have expressions referring to objects in table1.

Then, when table1 is removed, the rule will not be removed as its linked to
a chain in table2. When expressions in the rule are processed or removed,
that will lead to a use-after-free.

When looking for chains by ID, use the table that was used for the lookup
by name, and only return chains belonging to that same table.


Affected upstream versions: 5.9
Fixed upstream versions: 0, 5.10.137, 5.15.61, 5.18.18, 5.19.2, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 9e7dcb88ec8e85e4a8ad0ea494ea2f90f32d2583
CVE-2022-50213: kernel: netfilter: nf_tables: do not allow SET_ID to refer to another table
Component: kernel
Severity: Moderate
CWE: CWE-825 (Expired 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: 2025-06-18T00:00:00+00:00

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

netfilter: nf_tables: do not allow SET_ID to refer to another table

When doing lookups for sets on the same batch by using its ID, a set from a
different table can be used.

Then, when the table is removed, a reference to the set may be kept after
the set is freed, leading to a potential use-after-free.

When looking for sets by ID, use the table that was used for the lookup by
name, and only return sets belonging to that same table.

This fixes CVE-2022-2586, also reported as ZDI-CAN-17470.


Affected upstream versions: 3.16
Fixed upstream versions: 0, 4.19.256, 5.10.137, 5.15.61, 5.18.18, 5.19.2, 5.4.211, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 77d3b5038b7462318f5183e2ad704b01d57215a2
CVE-2022-50215: kernel: scsi: sg: Allow waiting for commands to complete on removed device
Component: kernel
Severity: Moderate
CWE: CWE-826 (Premature Release of Resource During Expected Lifetime)
CVSS v3: 6 (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:L)
Public date: 2025-06-18T00:00:00+00:00

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

scsi: sg: Allow waiting for commands to complete on removed device

When a SCSI device is removed while in active use, currently sg will
immediately return -ENODEV on any attempt to wait for active commands that
were sent before the removal.  This is problematic for commands that use
SG_FLAG_DIRECT_IO since the data buffer may still be in use by the kernel
when userspace frees or reuses it after getting ENODEV, leading to
corrupted userspace memory (in the case of READ-type commands) or corrupted
data being sent to the device (in the case of WRITE-type commands).  This
has been seen in practice when logging out of a iscsi_tcp session, where
the iSCSI driver may still be processing commands after the device has been
marked for removal.

Change the policy to allow userspace to wait for active sg commands even
when the device is being removed.  Return -ENODEV only when there are no
more responses to read.


Affected upstream versions: 2.6.28.10 < 2.6.29, 2.6.29.2 < 2.6.30, 2.6.30
Fixed upstream versions: 0, 2.6.29, 2.6.30, 4.14.291, 4.19.256, 4.9.326, 5.10.137, 5.15.61, 5.18.18, 5.19.2, 5.4.211, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: bbc118acf7baf9e93c5e1314d14f481301af4d0f
CVE-2022-50219: kernel: bpf: Fix KASAN use-after-free Read in compute_effective_progs
Component: kernel
Severity: Moderate
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: 2025-06-18T00:00:00+00:00

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

bpf: Fix KASAN use-after-free Read in compute_effective_progs

Syzbot found a Use After Free bug in compute_effective_progs().
The reproducer creates a number of BPF links, and causes a fault
injected alloc to fail, while calling bpf_link_detach on them.
Link detach triggers the link to be freed by bpf_link_free(),
which calls __cgroup_bpf_detach() and update_effective_progs().
If the memory allocation in this function fails, the function restores
the pointer to the bpf_cgroup_link on the cgroup list, but the memory
gets freed just after it returns. After this, every subsequent call to
update_effective_progs() causes this already deallocated pointer to be
dereferenced in prog_list_length(), and triggers KASAN UAF error.

To fix this issue don't preserve the pointer to the prog or link in the
list, but remove it and replace it with a dummy prog without shrinking
the table. The subsequent call to __cgroup_bpf_detach() or
__cgroup_bpf_detach() will correct it.


Affected upstream versions: 5.7
Fixed upstream versions: 0, 5.10.138, 5.15.61, 5.18.18, 5.19.2, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 3527e3cbb84d8868c4d4e91ba55915f96d39ec3d
CVE-2022-50221: kernel: drm/fb-helper: Fix out-of-bounds access
Component: kernel
Severity: Moderate
CWE: CWE-787 (Out-of-bounds Write)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

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

drm/fb-helper: Fix out-of-bounds access

Clip memory range to screen-buffer size to avoid out-of-bounds access
in fbdev deferred I/O's damage handling.

Fbdev's deferred I/O can only track pages. From the range of pages, the
damage handler computes the clipping rectangle for the display update.
If the fbdev screen buffer ends near the beginning of a page, that page
could contain more scanlines. The damage handler would then track these
non-existing scanlines as dirty and provoke an out-of-bounds access
during the screen update. Hence, clip the maximum memory range to the
size of the screen buffer.

While at it, rename the variables min/max to min_off/max_off in
drm_fb_helper_deferred_io(). This avoids confusion with the macros of
the same name.


Affected upstream versions: 5.18
Fixed upstream versions: 0, 5.19.2, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 9c49ac792c639dbec0728b513329a32461f72253