Critical security advisoryCriticalFlagged by our vulnerability database: A flaw in WordPress’s own updater is being exploited. Sites need 7.1.4. See if your site is affectedFlagged by our vulnerability database: WordPress updater flaw is being exploited. DetailsExploited: WordPress 7.1.4. Check your site
HuttenlocherTechnologies
Updated 9 h ago

Vulnerability database

Every flaw the U.S. government’s cybersecurity agency (CISA) has confirmed attackers are using, plus the new WordPress plugin and theme bugs published each day, sorted by what they mean for a small business. We refresh it twice a day. If you see something your website or office runs, tell us.

1,773exploited flaws on CISA’s list
34added in the last 30 days
495new WordPress flaws this week
395,110entries in the database

18,763 results · page 273 of 376

  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: macsec: fix UAF bug for real_dev Create a new macsec device but not get reference to real_CVE-2022-49390 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

    In the Linux kernel, the following vulnerability has been resolved: macsec: fix UAF bug for real_dev Create a new macsec device but not get reference to real_dev. That can not ensure that real_dev is freed after macsec. That will trigger the UAF bug for real_dev as following: ================================================================== BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 Call Trace: ... macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 dev_get_iflink+0x73/0xe0 net/core/dev.c:637 default_operstate net/core/link_watch.c:42 [inline] rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54 linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161 Allocated by task 22209: ... alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549 rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235 veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748 Freed by task 8: ... kfree+0xd6/0x4d0 mm/slub.c:4552 kvfree+0x42/0x50 mm/util.c:615 device_release+0x9f/0x240 drivers/base/core.c:2229 kobject_cleanup lib/kobject.c:673 [inline] kobject_release lib/kobject.c:704 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1c8/0x540 lib/kob

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: usb: usbip: fix a refcount leak in stub_probe() usb_get_dev() is called in stub_device_allCVE-2022-49389 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: usb: usbip: fix a refcount leak in stub_probe() usb_get_dev() is called in stub_device_alloc(). When stub_probe() fails after that, usb_put_dev() needs to be called to release the reference. Fix this by moving usb_put_dev() to sdev_free error path handling. Find this by code review.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: ubi: ubi_create_volume: Fix use-after-free when volume creation failed There is an use-aftCVE-2022-49388 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

    In the Linux kernel, the following vulnerability has been resolved: ubi: ubi_create_volume: Fix use-after-free when volume creation failed There is an use-after-free problem for 'eba_tbl' in ubi_create_volume()'s error handling path: ubi_eba_replace_table(vol, eba_tbl) vol->eba_tbl = tbl out_mapping: ubi_eba_destroy_table(eba_tbl) // Free 'eba_tbl' out_unlock: put_device(&vol->dev) vol_release kfree(tbl->entries) // UAF Fix it by removing redundant 'eba_tbl' releasing. Fetch a reproducer in [Link].

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: watchdog: rzg2l_wdt: Fix 32bit overflow issue The value of timer_cycle_us can be 0 due to CVE-2022-49387 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: watchdog: rzg2l_wdt: Fix 32bit overflow issue The value of timer_cycle_us can be 0 due to 32bit overflow. For eg:- If we assign the counter value "0xfff" for computing maxval. This patch fixes this issue by appending ULL to 1024, so that it is promoted to 64bit. This patch also fixes the warning message, 'watchdog: Invalid min and max timeout values, resetting to 0!'.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: am65-cpsw-nuss: Fix some refcount leaks of_get_child_by_name() returns CVE-2022-49386 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: am65-cpsw-nuss: Fix some refcount leaks of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. am65_cpsw_init_cpts() and am65_cpsw_nuss_probe() don't release the refcount in error case. Add missing of_node_put() to avoid refcount leak.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: driver: base: fix UAF when driver_attach failed When driver_attach(drv); failed, the driveCVE-2022-49385 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

    In the Linux kernel, the following vulnerability has been resolved: driver: base: fix UAF when driver_attach failed When driver_attach(drv); failed, the driver_private will be freed. But it has been added to the bus, which caused a UAF. To fix it, we need to delete it from the bus when failed.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: md: fix double free of io_acct_set bioset Now io_acct_set is alloc and free in personalityCVE-2022-49384 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

    In the Linux kernel, the following vulnerability has been resolved: md: fix double free of io_acct_set bioset Now io_acct_set is alloc and free in personality. Remove the codes that free io_acct_set in md_free and md_stop.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: watchdog: rzg2l_wdt: Fix 'BUG: Invalid wait context' This patch fixes the issue 'BUG: InvaCVE-2022-49383 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: watchdog: rzg2l_wdt: Fix 'BUG: Invalid wait context' This patch fixes the issue 'BUG: Invalid wait context' during restart() callback by using clk_prepare_enable() instead of pm_runtime_get_sync() for turning on the clocks during restart. This issue is noticed when testing with renesas_defconfig. [ 42.213802] reboot: Restarting system [ 42.217860] [ 42.219364] ============================= [ 42.223368] [ BUG: Invalid wait context ] [ 42.227372] 5.17.0-rc5-arm64-renesas-00002-g10393723e35e #522 Not tainted [ 42.234153] ----------------------------- [ 42.238155] systemd-shutdow/1 is trying to lock: [ 42.242766] ffff00000a650828 (&genpd->mlock){+.+.}-{3:3}, at: genpd_lock_mtx+0x14/0x20 [ 42.250709] other info that might help us debug this: [ 42.255753] context-{4:4} [ 42.258368] 2 locks held by systemd-shutdow/1: [ 42.262806] #0: ffff80000944e1c8 (system_transition_mutex#2){+.+.}-{3:3}, at: __do_sys_reboot+0xd0/0x250 [ 42.272388] #1: ffff8000094c4e40 (rcu_read_lock){....}-{1:2}, at: atomic_notifier_call_chain+0x0/0x150 [ 42.281795] stack backtrace: [ 42.284672] CPU: 0 PID: 1 Comm: s

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: soc: rockchip: Fix refcount leak in rockchip_grf_init of_find_matching_node_and_match retuCVE-2022-49382 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: soc: rockchip: Fix refcount leak in rockchip_grf_init of_find_matching_node_and_match returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: jffs2: fix memory leak in jffs2_do_fill_super If jffs2_iget() or d_make_root() in jffs2_doCVE-2022-49381 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: jffs2: fix memory leak in jffs2_do_fill_super If jffs2_iget() or d_make_root() in jffs2_do_fill_super() returns an error, we can observe the following kmemleak report: -------------------------------------------- unreferenced object 0xffff888105a65340 (size 64): comm "mount", pid 710, jiffies 4302851558 (age 58.239s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff859c45e5>] kmem_cache_alloc_trace+0x475/0x8a0 [<ffffffff86160146>] jffs2_sum_init+0x96/0x1a0 [<ffffffff86140e25>] jffs2_do_mount_fs+0x745/0x2120 [<ffffffff86149fec>] jffs2_do_fill_super+0x35c/0x810 [<ffffffff8614aae9>] jffs2_fill_super+0x2b9/0x3b0 [...] unreferenced object 0xffff8881bd7f0000 (size 65536): comm "mount", pid 710, jiffies 4302851558 (age 58.239s) hex dump (first 32 bytes): bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ backtrace: [<ffffffff858579ba>] kmalloc_order+0xda/0

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid f2fs_bug_on() in dec_valid_node_count() As Yanming reported in bugzillaCVE-2022-49380 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid f2fs_bug_on() in dec_valid_node_count() As Yanming reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215897 I have encountered a bug in F2FS file system in kernel v5.17. The kernel should enable CONFIG_KASAN=y and CONFIG_KASAN_INLINE=y. You can reproduce the bug by running the following commands: The kernel message is shown below: kernel BUG at fs/f2fs/f2fs.h:2511! Call Trace: f2fs_remove_inode_page+0x2a2/0x830 f2fs_evict_inode+0x9b7/0x1510 evict+0x282/0x4e0 do_unlinkat+0x33a/0x540 __x64_sys_unlinkat+0x8e/0xd0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae The root cause is: .total_valid_block_count or .total_valid_node_count could fuzzed to zero, then once dec_valid_node_count() was called, it will cause BUG_ON(), this patch fixes to print warning info and set SBI_NEED_FSCK into CP instead of panic.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: driver core: Fix wait_for_device_probe() & deferred_probe_timeout interaction Mounting NFSCVE-2022-49379 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: driver core: Fix wait_for_device_probe() & deferred_probe_timeout interaction Mounting NFS rootfs was timing out when deferred_probe_timeout was non-zero [1]. This was because ip_auto_config() initcall times out waiting for the network interfaces to show up when deferred_probe_timeout was non-zero. While ip_auto_config() calls wait_for_device_probe() to make sure any currently running deferred probe work or asynchronous probe finishes, that wasn't sufficient to account for devices being deferred until deferred_probe_timeout. Commit 35a672363ab3 ("driver core: Ensure wait_for_device_probe() waits until the deferred_probe_timeout fires") tried to fix that by making sure wait_for_device_probe() waits for deferred_probe_timeout to expire before returning. However, if wait_for_device_probe() is called from the kernel_init() context: - Before deferred_probe_initcall() [2], it causes the boot process to hang due to a deadlock. - After deferred_probe_initcall() [3], it blocks kernel_init() from continuing till deferred_probe_timeout expires and beats the point of deferred_probe_timeout that's trying to wait fo

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: sfc: fix considering that all channels have TX queues Normally, all channels have RX and TCVE-2022-49378 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: sfc: fix considering that all channels have TX queues Normally, all channels have RX and TX queues, but this is not true if modparam efx_separate_tx_channels=1 is used. In that cases, some channels only have RX queues and others only TX queues (or more preciselly, they have them allocated, but not initialized). Fix efx_channel_has_tx_queues to return the correct value for this case too. Messages shown at probe time before the fix: sfc 0000:03:00.0 ens6f0np0: MC command 0x82 inlen 544 failed rc=-22 (raw=0) arg=0 ------------[ cut here ]------------ netdevice: ens6f0np0: failed to initialise TXQ -1 WARNING: CPU: 1 PID: 626 at drivers/net/ethernet/sfc/ef10.c:2393 efx_ef10_tx_init+0x201/0x300 [sfc] [...] stripped RIP: 0010:efx_ef10_tx_init+0x201/0x300 [sfc] [...] stripped Call Trace: efx_init_tx_queue+0xaa/0xf0 [sfc] efx_start_channels+0x49/0x120 [sfc] efx_start_all+0x1f8/0x430 [sfc] efx_net_open+0x5a/0xe0 [sfc] __dev_open+0xd0/0x190 __dev_change_flags+0x1b3/0x220 dev_change_flags+0x21/0x60 [...] stripped Messages shown at remove time before the fix: sfc 0000:03:00.0 ens6f0np0: failed to fl

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: blk-mq: don't touch ->tagset in blk_mq_get_sq_hctx blk_mq_run_hw_queues() could be run wheCVE-2022-49377 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

    In the Linux kernel, the following vulnerability has been resolved: blk-mq: don't touch ->tagset in blk_mq_get_sq_hctx blk_mq_run_hw_queues() could be run when there isn't queued request and after queue is cleaned up, at that time tagset is freed, because tagset lifetime is covered by driver, and often freed after blk_cleanup_queue() returns. So don't touch ->tagset for figuring out current default hctx by the mapping built in request queue, so use-after-free on tagset can be avoided. Meantime this way should be fast than retrieving mapping from tagset.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix potential NULL pointer dereference If sd_probe() sees an early error before CVE-2022-49376 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix potential NULL pointer dereference If sd_probe() sees an early error before sdkp->device is initialized, sd_zbc_release_disk() is called. This causes a NULL pointer dereference when sd_is_zoned() is called inside that function. Avoid this by removing the call to sd_zbc_release_disk() in sd_probe() error path. This change is safe and does not result in zone information memory leakage because the zone information for a zoned disk is allocated only when sd_revalidate_disk() is called, at which point sdkp->disk_dev is fully set, resulting in sd_disk_release() being called when needed to cleanup a disk zone information using sd_zbc_release_disk().

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: rtc: mt6397: check return value after calling platform_get_resource() It will cause null-pCVE-2022-49375 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: rtc: mt6397: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: tipc: check attribute length for bearer name syzbot reported uninit-value: ===============CVE-2022-49374 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: tipc: check attribute length for bearer name syzbot reported uninit-value: ===================================================== BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:644 [inline] BUG: KMSAN: uninit-value in string+0x4f9/0x6f0 lib/vsprintf.c:725 string_nocheck lib/vsprintf.c:644 [inline] string+0x4f9/0x6f0 lib/vsprintf.c:725 vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806 vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158 vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256 vprintk_default+0x86/0xa0 kernel/printk/printk.c:2283 vprintk+0x15f/0x180 kernel/printk/printk_safe.c:50 _printk+0x18d/0x1cf kernel/printk/printk.c:2293 tipc_enable_bearer net/tipc/bearer.c:371 [inline] __tipc_nl_bearer_enable+0x2022/0x22a0 net/tipc/bearer.c:1033 tipc_nl_bearer_enable+0x6c/0xb0 net/tipc/bearer.c:1042 genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline] - Do sanity check the attribute length for TIPC_NLA_BEARER_NAME. - Do not use 'illegal name' in printing message.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: watchdog: ts4800_wdt: Fix refcount leak in ts4800_wdt_probe of_parse_phandle() returns a nCVE-2022-49373 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: watchdog: ts4800_wdt: Fix refcount leak in ts4800_wdt_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() in some error paths.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: tcp: tcp_rtx_synack() can be called from process context Laurent reported the enclosed repCVE-2022-49372 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: tcp: tcp_rtx_synack() can be called from process context Laurent reported the enclosed report [1] This bug triggers with following coditions: 0) Kernel built with CONFIG_DEBUG_PREEMPT=y 1) A new passive FastOpen TCP socket is created. This FO socket waits for an ACK coming from client to be a complete ESTABLISHED one. 2) A socket operation on this socket goes through lock_sock() release_sock() dance. 3) While the socket is owned by the user in step 2), a retransmit of the SYN is received and stored in socket backlog. 4) At release_sock() time, the socket backlog is processed while in process context. 5) A SYNACK packet is cooked in response of the SYN retransmit. 6) -> tcp_rtx_synack() is called in process context. Before blamed commit, tcp_rtx_synack() was always called from BH handler, from a timer handler. Fix this by using TCP_INC_STATS() & NET_INC_STATS() which do not assume caller is in non preemptible context. [1] BUG: using __this_cpu_add() in preemptible [00000000] code: epollpep/2180 caller is tcp_rtx_synack.part.0+0x36/0xc0 CPU: 10 PID: 2180 Comm: epollpep Tainted: G OE

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: driver core: fix deadlock in __device_attach In __device_attach function, The lock holdingCVE-2022-49371 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: driver core: fix deadlock in __device_attach In __device_attach function, The lock holding logic is as follows: ... __device_attach device_lock(dev) // get lock dev async_schedule_dev(__device_attach_async_helper, dev); // func async_schedule_node async_schedule_node_domain(func) entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC); /* when fail or work limit, sync to execute func, but __device_attach_async_helper will get lock dev as well, which will lead to A-A deadlock. */ if (!entry || atomic_read(&entry_count) > MAX_WORK) { func; else queue_work_node(node, system_unbound_wq, &entry->work) device_unlock(dev) As shown above, when it is allowed to do async probes, because of out of memory or work limit, async work is not allowed, to do sync execute instead. it will lead to A-A deadlock because of __device_attach_async_helper getting lock dev. To fix the deadlock, move the async_schedule_dev outside device_lock, as we can see, in async_schedule_node_domain, the parameter of queue_work_node is system_unbound_wq, so it can accept concurrent operations. which will a

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: firmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handle kobject_init_and_add() tCVE-2022-49370 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: firmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handle kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add() If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Fix this issue by calling kobject_put().

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: amt: fix possible memory leak in amt_rcv() If an amt receives packets and it finds socket.CVE-2022-49369 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: amt: fix possible memory leak in amt_rcv() If an amt receives packets and it finds socket. If it can't find a socket, it should free a received skb. But it doesn't. So, a memory leak would possibly occur.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk_eth_soc: out of bounds read in mtk_hwlro_get_fdir_entry() The "fsp->locCVE-2022-49368 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.1

    In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk_eth_soc: out of bounds read in mtk_hwlro_get_fdir_entry() The "fsp->location" variable comes from user via ethtool_get_rxnfc(). Check that it is valid to prevent an out of bounds read.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Fix refcount leak in mv88e6xxx_mdios_register of_get_child_by_name() CVE-2022-49367 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Fix refcount leak in mv88e6xxx_mdios_register of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. mv88e6xxx_mdio_register() pass the device node to of_mdiobus_register(). We don't need the device node after it. Add missing of_node_put() to avoid refcount leak.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix reference count leak in smb_check_perm_dacl() The issue happens in a specific pCVE-2022-49366 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix reference count leak in smb_check_perm_dacl() The issue happens in a specific path in smb_check_perm_dacl(). When "id" and "uid" have the same value, the function simply jumps out of the loop without decrementing the reference count of the object "posix_acls", which is increased by get_acl() earlier. This may result in memory leaks. Fix it by decreasing the reference count of "posix_acls" before jumping to label "check_access_bits".

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Off by one in dm_dmub_outbox1_low_irq() The > ARRAY_SIZE() should be >= ARRAY_CVE-2022-49365 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Off by one in dm_dmub_outbox1_low_irq() The > ARRAY_SIZE() should be >= ARRAY_SIZE() to prevent an out of bounds access.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to clear dirty inode in f2fs_evict_inode() As Yanming reported in bugzilla: httCVE-2022-49364 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to clear dirty inode in f2fs_evict_inode() As Yanming reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215904 The kernel message is shown below: kernel BUG at fs/f2fs/inode.c:825! Call Trace: evict+0x282/0x4e0 __dentry_kill+0x2b2/0x4d0 shrink_dentry_list+0x17c/0x4f0 shrink_dcache_parent+0x143/0x1e0 do_one_tree+0x9/0x30 shrink_dcache_for_umount+0x51/0x120 generic_shutdown_super+0x5c/0x3a0 kill_block_super+0x90/0xd0 kill_f2fs_super+0x225/0x310 deactivate_locked_super+0x78/0xc0 cleanup_mnt+0x2b7/0x480 task_work_run+0xc8/0x150 exit_to_user_mode_prepare+0x14a/0x150 syscall_exit_to_user_mode+0x1d/0x40 do_syscall_64+0x48/0x90 The root cause is: inode node and dnode node share the same nid, so during f2fs_evict_inode(), dnode node truncation will invalidate its NAT entry, so when truncating inode node, it fails due to invalid NAT entry, result in inode is still marked as dirty, fix this issue by clearing dirty for inode and setting SBI_NEED_FSCK flag in filesystem. output from dump.f2fs: [print_node_info: 354] Node ID [0xf:15] is inode i_nid[0] [0x

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on block address in f2fs_do_zero_range() As Yanming reported CVE-2022-49363 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

    In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on block address in f2fs_do_zero_range() As Yanming reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215894 I have encountered a bug in F2FS file system in kernel v5.17. I have uploaded the system call sequence as case.c, and a fuzzed image can be found in google net disk The kernel should enable CONFIG_KASAN=y and CONFIG_KASAN_INLINE=y. You can reproduce the bug by running the following commands: kernel BUG at fs/f2fs/segment.c:2291! Call Trace: f2fs_invalidate_blocks+0x193/0x2d0 f2fs_fallocate+0x2593/0x4a70 vfs_fallocate+0x2a5/0xac0 ksys_fallocate+0x35/0x70 __x64_sys_fallocate+0x8e/0xf0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae The root cause is, after image was fuzzed, block mapping info in inode will be inconsistent with SIT table, so in f2fs_fallocate(), it will cause panic when updating SIT with invalid blkaddr. Let's fix the issue by adding sanity check on block address before updating SIT table with it.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix potential use-after-free in nfsd_file_put() nfsd_file_put_noref() can free @nf, CVE-2022-49362 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8

    In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix potential use-after-free in nfsd_file_put() nfsd_file_put_noref() can free @nf, so don't dereference @nf immediately upon return from nfsd_file_put_noref().

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check for inline inode Yanming reported a kernel bug in Bugzilla keCVE-2022-49361 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check for inline inode Yanming reported a kernel bug in Bugzilla kernel [1], which can be reproduced. The bug message is: The kernel message is shown below: kernel BUG at fs/inode.c:611! Call Trace: evict+0x282/0x4e0 __dentry_kill+0x2b2/0x4d0 dput+0x2dd/0x720 do_renameat2+0x596/0x970 __x64_sys_rename+0x78/0x90 do_syscall_64+0x3b/0x90 [1] https://bugzilla.kernel.org/show_bug.cgi?id=215895 The bug is due to fuzzed inode has both inline_data and encrypted flags. During f2fs_evict_inode(), as the inode was deleted by rename(), it will cause inline data conversion due to conflicting flags. The page cache will be polluted and the panic will be triggered in clear_inode(). Try fixing the bug by doing more sanity checks for inline data inode in sanity_check_inode().

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on total_data_blocks As Yanming reported in bugzilla: https:CVE-2022-49360 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on total_data_blocks As Yanming reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215916 The kernel message is shown below: kernel BUG at fs/f2fs/segment.c:2560! Call Trace: allocate_segment_by_default+0x228/0x440 f2fs_allocate_data_block+0x13d1/0x31f0 do_write_page+0x18d/0x710 f2fs_outplace_write_data+0x151/0x250 f2fs_do_write_data_page+0xef9/0x1980 move_data_page+0x6af/0xbc0 do_garbage_collect+0x312f/0x46f0 f2fs_gc+0x6b0/0x3bc0 f2fs_balance_fs+0x921/0x2260 f2fs_write_single_data_page+0x16be/0x2370 f2fs_write_cache_pages+0x428/0xd00 f2fs_write_data_pages+0x96e/0xd50 do_writepages+0x168/0x550 __writeback_single_inode+0x9f/0x870 writeback_sb_inodes+0x47d/0xb20 __writeback_inodes_wb+0xb2/0x200 wb_writeback+0x4bd/0x660 wb_workfn+0x5f3/0xab0 process_one_work+0x79f/0x13e0 worker_thread+0x89/0xf60 kthread+0x26a/0x300 ret_from_fork+0x22/0x30 RIP: 0010:new_curseg+0xe8d/0x15f0 The root cause is: ckpt.valid_block_count is inconsistent with SIT table, stat info indicates filesystem has free blocks, but SIT table indicates filesystem has no free segment.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: drm/panfrost: Job should reference MMU not file_priv For a while now it's been allowed forCVE-2022-49359 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

    In the Linux kernel, the following vulnerability has been resolved: drm/panfrost: Job should reference MMU not file_priv For a while now it's been allowed for a MMU context to outlive it's corresponding panfrost_priv, however the job structure still references panfrost_priv to get hold of the MMU context. If panfrost_priv has been freed this is a use-after-free which I've been able to trigger resulting in a splat. To fix this, drop the reference to panfrost_priv in the job structure and add a direct reference to the MMU structure which is what's actually needed.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: memleak flow rule from commit path Abort path release flow rule objeCVE-2022-49358 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: memleak flow rule from commit path Abort path release flow rule object, however, commit path does not. Update code to destroy these objects before releasing the transaction.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: efi: Do not import certificates from UEFI Secure Boot for T2 Macs On Apple T2 Macs, when LCVE-2022-49357 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: efi: Do not import certificates from UEFI Secure Boot for T2 Macs On Apple T2 Macs, when Linux attempts to read the db and dbx efi variables at early boot to load UEFI Secure Boot certificates, a page fault occurs in Apple firmware code and EFI runtime services are disabled with the following logs: [Firmware Bug]: Page fault caused by firmware at PA: 0xffffb1edc0068000 WARNING: CPU: 3 PID: 104 at arch/x86/platform/efi/quirks.c:735 efi_crash_gracefully_on_page_fault+0x50/0xf0 (Removed some logs from here) Call Trace: <TASK> page_fault_oops+0x4f/0x2c0 ? search_bpf_extables+0x6b/0x80 ? search_module_extables+0x50/0x80 ? search_exception_tables+0x5b/0x60 kernelmode_fixup_or_oops+0x9e/0x110 __bad_area_nosemaphore+0x155/0x190 bad_area_nosemaphore+0x16/0x20 do_kern_addr_fault+0x8c/0xa0 exc_page_fault+0xd8/0x180 asm_exc_page_fault+0x1e/0x30 (Removed some logs from here) ? __efi_call+0x28/0x30 ? switch_mm+0x20/0x30 ? efi_call_rts+0x19a/0x8e0 ? process_one_work+0x222/0x3f0 ? worker_thread+0x4a/0x3d0 ? kthread+0x17a/0x1a0 ? process_one_work+0x3f0/0x3f0 ? set_kthread_struct+0x40/0x40 ? ret_from_fork+0x22

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Trap RDMA segment overflows Prevent svc_rdma_build_writes() from walking off the eCVE-2022-49356 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8

    In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Trap RDMA segment overflows Prevent svc_rdma_build_writes() from walking off the end of a Write chunk's segment array. Caught with KASAN. The test that this fix replaces is invalid, and might have been left over from an earlier prototype of the PCL work.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: ata: pata_octeon_cf: Fix refcount leak in octeon_cf_probe of_find_device_by_node() takes rCVE-2022-49354 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: ata: pata_octeon_cf: Fix refcount leak in octeon_cf_probe of_find_device_by_node() takes reference, we should use put_device() to release it when not need anymore. Add missing put_device() to avoid refcount leak.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: powerpc/papr_scm: don't requests stats with '0' sized stats buffer Sachin reported [1] thaCVE-2022-49353 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: powerpc/papr_scm: don't requests stats with '0' sized stats buffer Sachin reported [1] that on a POWER-10 lpar he is seeing a kernel panic being reported with vPMEM when papr_scm probe is being called. The panic is of the form below and is observed only with following option disabled(profile) for the said LPAR 'Enable Performance Information Collection' in the HMC: Kernel attempted to write user page (1c) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on write at 0x0000001c Faulting instruction address: 0xc008000001b90844 Oops: Kernel access of bad area, sig: 11 [#1] <snip> NIP [c008000001b90844] drc_pmem_query_stats+0x5c/0x270 [papr_scm] LR [c008000001b92794] papr_scm_probe+0x2ac/0x6ec [papr_scm] Call Trace: 0xc00000000941bca0 (unreliable) papr_scm_probe+0x2ac/0x6ec [papr_scm] platform_probe+0x98/0x150 really_probe+0xfc/0x510 __driver_probe_device+0x17c/0x230 <snip> ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception On investigation looks like this panic was caused due to a 'stat_buffer' of size==0 being provided to drc

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: ext4: fix warning in ext4_handle_inode_extension We got issue as follows: EXT4-fs error (dCVE-2022-49352 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: ext4: fix warning in ext4_handle_inode_extension We got issue as follows: EXT4-fs error (device loop0) in ext4_reserve_inode_write:5741: Out of memory EXT4-fs error (device loop0): ext4_setattr:5462: inode #13: comm syz-executor.0: mark_inode_dirty error EXT4-fs error (device loop0) in ext4_setattr:5519: Out of memory EXT4-fs error (device loop0): ext4_ind_map_blocks:595: inode #13: comm syz-executor.0: Can't allocate blocks for non-extent mapped inodes with bigalloc ------------[ cut here ]------------ WARNING: CPU: 1 PID: 4361 at fs/ext4/file.c:301 ext4_file_write_iter+0x11c9/0x1220 Modules linked in: CPU: 1 PID: 4361 Comm: syz-executor.0 Not tainted 5.10.0+ #1 RIP: 0010:ext4_file_write_iter+0x11c9/0x1220 RSP: 0018:ffff924d80b27c00 EFLAGS: 00010282 RAX: ffffffff815a3379 RBX: 0000000000000000 RCX: 000000003b000000 RDX: ffff924d81601000 RSI: 00000000000009cc RDI: 00000000000009cd RBP: 000000000000000d R08: ffffffffbc5a2c6b R09: 0000902e0e52a96f R10: ffff902e2b7c1b40 R11: ffff902e2b7c1b40 R12: 000000000000000a R13: 0000000000000001 R14: ffff902e0e52aa10 R15: ffffffffffffff8b FS: 00007f81a7f65700(0000) GS:ffff902e

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: net: altera: Fix refcount leak in altera_tse_mdio_create Every iteration of for_each_childCVE-2022-49351 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: net: altera: Fix refcount leak in altera_tse_mdio_create Every iteration of for_each_child_of_node() decrements the reference count of the previous node. When break from a for_each_child_of_node() loop, we need to explicitly call of_node_put() on the child node when not need anymore. Add missing of_node_put() to avoid refcount leak.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: net: mdio: unexport __init-annotated mdio_bus_init() EXPORT_SYMBOL and __init is a bad comCVE-2022-49350 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: net: mdio: unexport __init-annotated mdio_bus_init() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it has been broken for a decade. Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds. There are two ways to fix it: - Remove __init - Remove EXPORT_SYMBOL I chose the latter for this case because the only in-tree call-site, drivers/net/phy/phy_device.c is never compiled as modular. (CONFIG_PHYLIB is boolean)

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: ext4: fix use-after-free in ext4_rename_dir_prepare We got issue as follows: EXT4-fs (loopCVE-2022-49349 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

    In the Linux kernel, the following vulnerability has been resolved: ext4: fix use-after-free in ext4_rename_dir_prepare We got issue as follows: EXT4-fs (loop0): mounted filesystem without journal. Opts: ,errors=continue ext4_get_first_dir_block: bh->b_data=0xffff88810bee6000 len=34478 ext4_get_first_dir_block: *parent_de=0xffff88810beee6ae bh->b_data=0xffff88810bee6000 ext4_rename_dir_prepare: [1] parent_de=0xffff88810beee6ae ================================================================== BUG: KASAN: use-after-free in ext4_rename_dir_prepare+0x152/0x220 Read of size 4 at addr ffff88810beee6ae by task rep/1895 CPU: 13 PID: 1895 Comm: rep Not tainted 5.10.0+ #241 Call Trace: dump_stack+0xbe/0xf9 print_address_description.constprop.0+0x1e/0x220 kasan_report.cold+0x37/0x7f ext4_rename_dir_prepare+0x152/0x220 ext4_rename+0xf44/0x1ad0 ext4_rename2+0x11c/0x170 vfs_rename+0xa84/0x1440 do_renameat2+0x683/0x8f0 __x64_sys_renameat+0x53/0x60 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f45a6fc41c9 RSP: 002b:00007ffc5a470218 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f45a6fc41c9 RDX: 000000

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: ext4: filter out EXT4_FC_REPLAY from on-disk superblock field s_state The EXT4_FC_REPLAY bCVE-2022-49348 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: ext4: filter out EXT4_FC_REPLAY from on-disk superblock field s_state The EXT4_FC_REPLAY bit in sbi->s_mount_state is used to indicate that we are in the middle of replay the fast commit journal. This was actually a mistake, since the sbi->s_mount_info is initialized from es->s_state. Arguably s_mount_state is misleadingly named, but the name is historical --- s_mount_state and s_state dates back to ext2. What should have been used is the ext4_{set,clear,test}_mount_flag() inline functions, which sets EXT4_MF_* bits in sbi->s_mount_flags. The problem with using EXT4_FC_REPLAY is that a maliciously corrupted superblock could result in EXT4_FC_REPLAY getting set in s_mount_state. This bypasses some sanity checks, and this can trigger a BUG() in ext4_es_cache_extent(). As a easy-to-backport-fix, filter out the EXT4_FC_REPLAY bit for now. We should eventually transition away from EXT4_FC_REPLAY to something like EXT4_MF_REPLAY.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: ext4: fix bug_on in ext4_writepages we got issue as follows: EXT4-fs error (device loop0):CVE-2022-49347 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: ext4: fix bug_on in ext4_writepages we got issue as follows: EXT4-fs error (device loop0): ext4_mb_generate_buddy:1141: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free cls ------------[ cut here ]------------ kernel BUG at fs/ext4/inode.c:2708! invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 2 PID: 2147 Comm: rep Not tainted 5.18.0-rc2-next-20220413+ #155 RIP: 0010:ext4_writepages+0x1977/0x1c10 RSP: 0018:ffff88811d3e7880 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88811c098000 RDX: 0000000000000000 RSI: ffff88811c098000 RDI: 0000000000000002 RBP: ffff888128140f50 R08: ffffffffb1ff6387 R09: 0000000000000000 R10: 0000000000000007 R11: ffffed10250281ea R12: 0000000000000001 R13: 00000000000000a4 R14: ffff88811d3e7bb8 R15: ffff888128141028 FS: 00007f443aed9740(0000) GS:ffff8883aef00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020007200 CR3: 000000011c2a4000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: net: dsa: lantiq_gswip: Fix refcount leak in gswip_gphy_fw_list Every iteration of for_eacCVE-2022-49346 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: net: dsa: lantiq_gswip: Fix refcount leak in gswip_gphy_fw_list 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 gphy_fw_np. Add missing of_node_put() to avoid refcount leak.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: net: xfrm: unexport __init-annotated xfrm4_protocol_init() EXPORT_SYMBOL and __init is a bCVE-2022-49345 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: net: xfrm: unexport __init-annotated xfrm4_protocol_init() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it has been broken for a decade. Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds. There are two ways to fix it: - Remove __init - Remove EXPORT_SYMBOL I chose the latter for this case because the only in-tree call-site, net/ipv4/xfrm4_policy.c is never compiled as modular. (CONFIG_XFRM is boolean)

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix a data-race in unix_dgram_peer_wake_me().CVE-2022-49344 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 4.7

    In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix a data-race in unix_dgram_peer_wake_me(). unix_dgram_poll() calls unix_dgram_peer_wake_me() without `other`'s lock held and check if its receive queue is full. Here we need to use unix_recvq_full_lockless() instead of unix_recvq_full(), otherwise KCSAN will report a data-race.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: ext4: avoid cycles in directory h-tree A maliciously corrupted filesystem can contain cyclCVE-2022-49343 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

    In the Linux kernel, the following vulnerability has been resolved: ext4: avoid cycles in directory h-tree A maliciously corrupted filesystem can contain cycles in the h-tree stored inside a directory. That can easily lead to the kernel corrupting tree nodes that were already verified under its hands while doing a node split and consequently accessing unallocated memory. Fix the problem by verifying traversed block numbers are unique.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: net: ethernet: bgmac: Fix refcount leak in bcma_mdio_mii_register of_get_child_by_name() rCVE-2022-49342 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: net: ethernet: bgmac: Fix refcount leak in bcma_mdio_mii_register of_get_child_by_name() 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.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: bpf, arm64: Clear prog->jited_len along prog->jited syzbot reported an illegal copy_to_useCVE-2022-49341 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: bpf, arm64: Clear prog->jited_len along prog->jited syzbot reported an illegal copy_to_user() attempt from bpf_prog_get_info_by_fd() [1] There was no repro yet on this bug, but I think that commit 0aef499f3172 ("mm/usercopy: Detect vmalloc overruns") is exposing a prior bug in bpf arm64. bpf_prog_get_info_by_fd() looks at prog->jited_len to determine if the JIT image can be copied out to user space. My theory is that syzbot managed to get a prog where prog->jited_len has been set to 43, while prog->bpf_func has ben cleared. It is not clear why copy_to_user(uinsns, NULL, ulen) is triggering this particular warning. I thought find_vma_area(NULL) would not find a vm_struct. As we do not hold vmap_area_lock spinlock, it might be possible that the found vm_struct was garbage. [1] usercopy: Kernel memory exposure attempt detected from vmalloc (offset 792633534417210172, size 43)! kernel BUG at mm/usercopy.c:101! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 25002 Comm: syz-executor.1 Not tainted 5.18.0-syzkaller-10139-g8291eaafed36 #0 Hardware name: linux,dummy-virt (DT) pstate: 60

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: ip_gre: test csum_start instead of transport header GRE with TUNNEL_CSUM will apply local CVE-2022-49340 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.1

    In the Linux kernel, the following vulnerability has been resolved: ip_gre: test csum_start instead of transport header GRE with TUNNEL_CSUM will apply local checksum offload on CHECKSUM_PARTIAL packets. ipgre_xmit must validate csum_start after an optional skb_pull, else lco_csum may trigger an overflow. The original check was if (csum && skb_checksum_start(skb) < skb->data) return -EINVAL; This had false positives when skb_checksum_start is undefined: when ip_summed is not CHECKSUM_PARTIAL. A discussed refinement was straightforward if (csum && skb->ip_summed == CHECKSUM_PARTIAL && skb_checksum_start(skb) < skb->data) return -EINVAL; But was eventually revised more thoroughly: - restrict the check to the only branch where needed, in an uncommon GRE path that uses header_ops and calls skb_pull. - test skb_transport_header, which is set along with csum_start in skb_partial_csum_set in the normal header_ops datapath. Turns out skbs can arrive in this branch without the transport header set, e.g., through BPF redirection. Revise the check back to check csum_start directly, and only if CHECKSUM_PARTIAL. Do leave the check in the updated location. Check field re

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.

Where this comes from: the exploited list is CISA’s Known Exploited Vulnerabilities catalog. Everything else is the whole National Vulnerability Database, where each record is published by the team that found the bug (Wordfence, Patchstack, WPScan, the vendors themselves and others); we show who. Exploit odds are FIRST’s EPSS, updated daily. Titles and categories are ours, so check the linked record before acting on a detail. For a write-up of the big ones, see our advisories. Every vendor, and every WordPress plugin and theme with a recorded flaw, also has its own page. All of it is free to reuse as JSON, CSV or RSS.

Weekly security brief

The flaws that hit local websites, every Friday.

One short email: what got exploited this week, which WordPress plugins broke, and what to check. Unsubscribe in one click.

Get in touch

Tell us what you're building.

A website, your marketing, a security check, an app, or the thing you've been running out of a spreadsheet for three years. A few lines is plenty.

01The person who'll do the work writes back
02A short call, then a written plan with the price
03Nothing starts until you say yes
04Hacked or down right now? Call, and we pick up the same day
843-331-6339

Not ready to talk yet? Run the free website check and see what Google sees.

What do you need?
Build
Grow
Protect
Urgent

No newsletter, no sales sequence. Just a reply.