Category Archives: Advisories

Advisories

LSN-0110-1: Kernel Live Patch Security Notice

Read Time:5 Minute, 25 Second

In the Linux kernel, the following vulnerability has been
resolved: tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc Any
unprivileged user can attach N_GSM0710 ldisc, but it requires CAP_NET_ADMIN
to create a GSM network anyway. Require initial namespace CAP_NET_ADMIN to
do that.)(CVE-2023-52880)

In the Linux kernel, the following vulnerability has been
resolved: net: openvswitch: fix overwriting ct original tuple for ICMPv6
OVS_PACKET_CMD_EXECUTE has 3 main attributes: – OVS_PACKET_ATTR_KEY –
Packet metadata in a netlink format. – OVS_PACKET_ATTR_PACKET – Binary
packet content. – OVS_PACKET_ATTR_ACTIONS – Actions to execute on the
packet. OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key
structure with the metadata like conntrack state, input port, recirculation
id, etc. Then the packet itself gets parsed to populate the rest of the
keys from the packet headers. Whenever the packet parsing code starts
parsing the ICMPv6 header, it first zeroes out fields in the key
corresponding to Neighbor Discovery information even if it is not an ND
packet. It is an ‘ipv6.nd’ field. However, the ‘ipv6’ is a union that
shares the space between ‘nd’ and ‘ct_orig’ that holds the original tuple
conntrack metadata parsed from the OVS_PACKET_ATTR_KEY. ND packets should
not normally have conntrack state, so it’s fine to share the space, but
normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the
state attached and it should not be overwritten. The issue results in all
but the last 4 bytes of the destination address being wiped from the
original conntrack tuple leading to incorrect packet matching and
potentially executing wrong actions in case this packet recirculates within
the datapath or goes back to userspace. ND fields should not be accessed in
non-ND packets, so not clearing them should be fine. Executing memset()
only for actual ND packets to avoid the issue. Initializing the whole thing
before parsing is needed because ND packet may not contain all the options.
The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn’t affect
packets entering OVS datapath from network interfaces, because in this case
CT metadata is populated from skb after the packet is already parsed.)(CVE-2024-38558)

In the Linux kernel, the following vulnerability has been
resolved: media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in
uvc_parse_format This can lead to out of bounds writes since frames of this
type were not taken into account when calculating the size of the frames
buffer in uvc_parse_streaming.)(CVE-2024-53104)

In the Linux kernel, the following vulnerability has been
resolved: netlink: terminate outstanding dump on socket close Netlink
supports iterative dumping of data. It provides the families the following
ops: – start – (optional) kicks off the dumping process – dump – actual
dump helper, keeps getting called until it returns 0 – done – (optional)
pairs with .start, can be used for cleanup The whole process is
asynchronous and the repeated calls to .dump don’t actually happen in a
tight loop, but rather are triggered in response to recvmsg() on the
socket. This gives the user full control over the dump, but also means that
the user can close the socket without getting to the end of the dump. To
make sure .start is always paired with .done we check if there is an
ongoing dump before freeing the socket, and if so call .done. The
complication is that sockets can get freed from BH and .done is allowed to
sleep. So we use a workqueue to defer the call, when needed. Unfortunately
this does not work correctly. What we defer is not the cleanup but rather
releasing a reference on the socket. We have no guarantee that we own the
last reference, if someone else holds the socket they may release it in BH
and we’re back to square one. The whole dance, however, appears to be
unnecessary. Only the user can interact with dumps, so we can clean up when
socket is closed. And close always happens in process context. Some async
code may still access the socket after close, queue notification skbs to it
etc. but no dumps can start, end or otherwise make progress. Delete the
workqueue and flush the dump state directly from the release handler. Note
that further cleanup is possible in -next, for instance we now always call
.done before releasing the main module reference, so dump doesn’t have to
take a reference of its own.)(CVE-2024-53140)

In the Linux kernel, the following vulnerability has been
resolved: blk-cgroup: Fix UAF in blkcg_unpin_online() blkcg_unpin_online()
walks up the blkcg hierarchy putting the online pin. To walk up, it uses
blkcg_parent(blkcg) but it was calling that after
blkcg_destroy_blkgs(blkcg) which could free the blkcg, leading to the
following UAF:
================================================================== BUG:
KASAN: slab-use-after-free in blkcg_unpin_online+0x15a/0x270 Read of size 8
at addr ffff8881057678c0 by task kworker/9:1/117 CPU: 9 UID: 0 PID: 117
Comm: kworker/9:1 Not tainted 6.13.0-rc1-work-00182-gb8f52214c61a-dirty #48
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown
02/02/2022 Workqueue: cgwb_release cgwb_release_workfn Call Trace:
dump_stack_lvl+0x27/0x80 print_report+0x151/0x710 kasan_report+0xc0/0x100
blkcg_unpin_online+0x15a/0x270 cgwb_release_workfn+0x194/0x480
process_scheduled_works+0x71b/0xe20 worker_thread+0x82a/0xbd0
kthread+0x242/0x2c0 ret_from_fork+0x33/0x70 ret_from_fork_asm+0x1a/0x30
… Freed by task 1944: kasan_save_track+0x2b/0x70
kasan_save_free_info+0x3c/0x50 __kasan_slab_free+0x33/0x50
kfree+0x10c/0x330 css_free_rwork_fn+0xe6/0xb30
process_scheduled_works+0x71b/0xe20 worker_thread+0x82a/0xbd0
kthread+0x242/0x2c0 ret_from_fork+0x33/0x70 ret_from_fork_asm+0x1a/0x30
Note that the UAF is not easy to trigger as the free path is indirected
behind a couple RCU grace periods and a work item execution. I could only
trigger it with artifical msleep() injected in blkcg_unpin_online(). Fix it
by reading the parent pointer before destroying the blkcg’s blkg’s.)(CVE-2024-56672)

Attila Szász discovered that the HFS+ file system implementation in the
Linux Kernel contained a heap overflow vulnerability. An attacker could use
a specially crafted file system image that, when mounted, could cause a
denial of service (system crash) or possibly execute arbitrary code.)(CVE-2025-0927)

Read More

Advisories

GitHub Actions Supply Chain Attack

Read Time:2 Minute, 1 Second

What is the Attack?Recently, a popular third-party GitHub Action tj-actions/changed-files GitHub Action (CVE-2025-30066)- used by over 23,000 repositories- was compromised, potentially exposing sensitive workflow secrets in any pipeline that integrated it.It was later discovered that the compromise of tj-actions/changed-files may be due to a similar compromise of another GitHub Action, reviewdog/action-setup@v1 (tracked as CVE-2025-30154). Multiple Reviewdog actions were compromised during a specific time period · CVE-2025-30154 · GitHub Advisory Database · GitHubGitHub Actions is a powerful CI/CD platform that enables users to automate their software development pipelines. Individual actions can be packaged as reusable workflow components, making them widely adoptable across projects. The supply chain compromise allows for information disclosure of secrets including, but not limited to, valid access keys, GitHub Personal Access Tokens (PATs), npm tokens, and private RSA keys.Both the issues have been assigned CVE numbers (CVE-2025-30066, CVE-2025-30154) and have been added to CISA’s Known Exploited Vulnerabilities Catalog. As this is an ongoing investigation, we will continue to monitor the situation and provide updates as more information becomes available.What is the recommended Mitigation?Review Github Advisory posted at https://github.com/advisories/GHSA-mrrh-fwg8-r2c3 and follow Mitigation steps as mentioned below:1. Identify usage: Search for the tj-actions/changed-files action and other actions mentioned above in your repositories to determine whether and where it has been used.2. Review workflow logs: Examine past workflow runs for evidence of secret exposure and update workflows referencing the compromised commit.3. Rotate potentially exposed secrets: As a precaution, rotate any secrets that may have been exposed during this timeframe to ensure the continued security of your workflows.4. Investigate malicious activity: If you encounter any signs that the compromised action has been executed, investigate further for any signs of malicious activity.See the following additional resource for further guidance:Security hardening for GitHub Actions – GitHub DocsWhat FortiGuard Coverage is available?FortiGuard Labs recommends users to follow instructions and mitigation steps as mentioned on the vendor’s advisory.The FortiGuard Incident Response team can be engaged to help with any suspected compromise.FortiGuard IPS signature is added to detect and block any malicious activity related to CVE-2025-30066 and CVE-2025-30154. Intrusion Prevention | FortiGuard LabsFortiGuard Labs will provide updates as more information and protections become available.

Read More

Advisories

suricata-7.0.10-1.el9

Read Time:28 Second

FEDORA-EPEL-2025-46a02bfa95

Packages in this update:

suricata-7.0.10-1.el9

Update description:

This is an extra release to address a critical issue in 7.0.9 affecting AF_PACKET users: setting a BPF would cause Suricata to fail to start up. This has been fixed.

Various security, performance, accuracy, and stability issues have been fixed. LibHTP has been updated to version 0.5.50 which is bundled with this new release. This fixes:

CVE-2025-29915: HIGH
CVE-2025-29917: HIGH
CVE-2025-29918: HIGH
CVE-2025-29916: Moderate

Read More

Advisories

suricata-7.0.10-1.el8

Read Time:28 Second

FEDORA-EPEL-2025-811cbc0ed6

Packages in this update:

suricata-7.0.10-1.el8

Update description:

This is an extra release to address a critical issue in 7.0.9 affecting AF_PACKET users: setting a BPF would cause Suricata to fail to start up. This has been fixed.

Various security, performance, accuracy, and stability issues have been fixed. LibHTP has been updated to version 0.5.50 which is bundled with this new release. This fixes:

CVE-2025-29915: HIGH
CVE-2025-29917: HIGH
CVE-2025-29918: HIGH
CVE-2025-29916: Moderate

Read More

Advisories

suricata-7.0.10-1.fc41

Read Time:28 Second

FEDORA-2025-5fa61dc843

Packages in this update:

suricata-7.0.10-1.fc41

Update description:

This is an extra release to address a critical issue in 7.0.9 affecting AF_PACKET users: setting a BPF would cause Suricata to fail to start up. This has been fixed.

Various security, performance, accuracy, and stability issues have been fixed. LibHTP has been updated to version 0.5.50 which is bundled with this new release. This fixes:

CVE-2025-29915: HIGH
CVE-2025-29917: HIGH
CVE-2025-29918: HIGH
CVE-2025-29916: Moderate

Read More