| Risiko / Label | Veröffentlichung | |
|---|---|---|
| Risiko ? / 10 CVE-2024-22119 | vor 5 Stunde(n) | |
| The cause of vulnerability is improper validation of form input field “Name” on Graph page in Items section. | ||
| Risiko ? / 10 CVE-2024-33883 | vor 9 Stunde(n) | |
| The ejs (aka Embedded JavaScript templates) package before 3.1.10 for Node.js lacks certain pollution protection. | ||
| Risiko ? / 10 CVE-2022-48631 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: fix bug in extents parsing when eh_entries == 0 and eh_depth > 0
When walking through an inode extents, the ext4_ext_binsearch_idx() function
assumes that the extent header has been previously validated. However, there
are no checks that verify that the number of entries (eh->eh_entries) is
non-zero when depth is > 0. And this will lead to problems because the
EXT_FIRST_INDEX() and EXT_LAST_INDEX() will return garbage and result in this:
[ 135.245946] ------------[ cut here ]------------
[ 135.247579] kernel BUG at fs/ext4/extents.c:2258!
[ 135.249045] invalid opcode: 0000 [#1] PREEMPT SMP
[ 135.250320] CPU: 2 PID: 238 Comm: tmp118 Not tainted 5.19.0-rc8+ #4
[ 135.252067] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014
[ 135.255065] RIP: 0010:ext4_ext_map_blocks+0xc20/0xcb0
[ 135.256475] Code:
[ 135.261433] RSP: 0018:ffffc900005939f8 EFLAGS: 00010246
[ 135.262847] RAX: 0000000000000024 RBX: ffffc90000593b70 RCX: 0000000000000023
[ 135.264765] RDX: ffff8880038e5f10 RSI: 0000000000000003 RDI: ffff8880046e922c
[ 135.266670] RBP: ffff8880046e9348 R08: 0000000000000001 R09: ffff888002ca580c
[ 135.268576] R10: 0000000000002602 R11: 0000000000000000 R12: 0000000000000024
[ 135.270477] R13: 0000000000000000 R14: 0000000000000024 R15: 0000000000000000
[ 135.272394] FS: 00007fdabdc56740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000
[ 135.274510] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 135.276075] CR2: 00007ffc26bd4f00 CR3: 0000000006261004 CR4: 0000000000170ea0
[ 135.277952] Call Trace:
[ 135.278635] |
||
| Risiko ? / 10 CVE-2022-48632 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved: i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction() memcpy() is called in a loop while 'operation->length' upper bound is not checked and 'data_idx' also increments. | ||
| Risiko ? / 10 CVE-2022-48633 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved:
drm/gma500: Fix WARN_ON(lock->magic != lock) error
psb_gem_unpin() calls dma_resv_lock() but the underlying ww_mutex
gets destroyed by drm_gem_object_release() move the
drm_gem_object_release() call in psb_gem_free_object() to after
the unpin to fix the below warning:
[ 79.693962] ------------[ cut here ]------------
[ 79.693992] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
[ 79.694015] WARNING: CPU: 0 PID: 240 at kernel/locking/mutex.c:582 __ww_mutex_lock.constprop.0+0x569/0xfb0
[ 79.694052] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer qrtr bnep ath9k ath9k_common ath9k_hw snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel ath3k snd_intel_dspcfg mac80211 snd_intel_sdw_acpi btusb snd_hda_codec btrtl btbcm btintel btmtk bluetooth at24 snd_hda_core snd_hwdep uvcvideo snd_seq libarc4 videobuf2_vmalloc ath videobuf2_memops videobuf2_v4l2 videobuf2_common snd_seq_device videodev acer_wmi intel_powerclamp coretemp mc snd_pcm joydev sparse_keymap ecdh_generic pcspkr wmi_bmof cfg80211 i2c_i801 i2c_smbus snd_timer snd r8169 rfkill lpc_ich soundcore acpi_cpufreq zram rtsx_pci_sdmmc mmc_core serio_raw rtsx_pci gma500_gfx(E) video wmi ip6_tables ip_tables i2c_dev fuse
[ 79.694436] CPU: 0 PID: 240 Comm: plymouthd Tainted: G W E 6.0.0-rc3+ #490
[ 79.694457] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013
[ 79.694469] RIP: 0010:__ww_mutex_lock.constprop.0+0x569/0xfb0
[ 79.694496] Code: ff 85 c0 0f 84 15 fb ff ff 8b 05 ca 3c 11 01 85 c0 0f 85 07 fb ff ff 48 c7 c6 30 cb 84 aa 48 c7 c7 a3 e1 82 aa e8 ac 29 f8 ff <0f> 0b e9 ed fa ff ff e8 5b 83 8a ff 85 c0 74 10 44 8b 0d 98 3c 11
[ 79.694513] RSP: 0018:ffffad1dc048bbe0 EFLAGS: 00010282
[ 79.694623] RAX: 0000000000000028 RBX: 0000000000000000 RCX: 0000000000000000
[ 79.694636] RDX: 0000000000000001 RSI: ffffffffaa8b0ffc RDI: 00000000ffffffff
[ 79.694650] RBP: ffffad1dc048bc80 R08: 0000000000000000 R09: ffffad1dc048ba90
[ 79.694662] R10: 0000000000000003 R11: ffffffffaad62fe8 R12: ffff9ff302103138
[ 79.694675] R13: ffff9ff306ec8000 R14: ffff9ff307779078 R15: ffff9ff3014c0270
[ 79.694690] FS: 00007ff1cccf1740(0000) GS:ffff9ff3bc200000(0000) knlGS:0000000000000000
[ 79.694705] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 79.694719] CR2: 0000559ecbcb4420 CR3: 0000000013210000 CR4: 00000000000006f0
[ 79.694734] Call Trace:
[ 79.694749] |
||
| Risiko ? / 10 CVE-2022-48637 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved: bnxt: prevent skb UAF after handing over to PTP worker When reading the timestamp is required bnxt_tx_int() hands over the ownership of the completed skb to the PTP worker. The skb should not be used afterwards, as the worker may run before the rest of our code and free the skb, leading to a use-after-free. Since dev_kfree_skb_any() accepts NULL make the loss of ownership more obvious and set skb to NULL. | ||
| Risiko ? / 10 CVE-2022-48640 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved: bonding: fix NULL deref in bond_rr_gen_slave_id Fix a NULL dereference of the struct bonding.rr_tx_counter member because if a bond is initially created with an initial mode != zero (Round Robin) the memory required for the counter is never created and when the mode is changed there is never any attempt to verify the memory is allocated upon switching modes. This causes the following Oops on an aarch64 machine: [ 334.686773] Unable to handle kernel paging request at virtual address ffff2c91ac905000 [ 334.694703] Mem abort info: [ 334.697486] ESR = 0x0000000096000004 [ 334.701234] EC = 0x25: DABT (current EL), IL = 32 bits [ 334.706536] SET = 0, FnV = 0 [ 334.709579] EA = 0, S1PTW = 0 [ 334.712719] FSC = 0x04: level 0 translation fault [ 334.717586] Data abort info: [ 334.720454] ISV = 0, ISS = 0x00000004 [ 334.724288] CM = 0, WnR = 0 [ 334.727244] swapper pgtable: 4k pages, 48-bit VAs, pgdp=000008044d662000 [ 334.733944] [ffff2c91ac905000] pgd=0000000000000000, p4d=0000000000000000 [ 334.740734] Internal error: Oops: 96000004 [#1] SMP [ 334.745602] Modules linked in: bonding tls veth rfkill sunrpc arm_spe_pmu vfat fat acpi_ipmi ipmi_ssif ixgbe igb i40e mdio ipmi_devintf ipmi_msghandler arm_cmn arm_dsu_pmu cppc_cpufreq acpi_tad fuse zram crct10dif_ce ast ghash_ce sbsa_gwdt nvme drm_vram_helper drm_ttm_helper nvme_core ttm xgene_hwmon [ 334.772217] CPU: 7 PID: 2214 Comm: ping Not tainted 6.0.0-rc4-00133-g64ae13ed4784 #4 [ 334.779950] Hardware name: GIGABYTE R272-P31-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021 [ 334.789244] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 334.796196] pc : bond_rr_gen_slave_id+0x40/0x124 [bonding] [ 334.801691] lr : bond_xmit_roundrobin_slave_get+0x38/0xdc [bonding] [ 334.807962] sp : ffff8000221733e0 [ 334.811265] x29: ffff8000221733e0 x28: ffffdbac8572d198 x27: ffff80002217357c [ 334.818392] x26: 000000000000002a x25: ffffdbacb33ee000 x24: ffff07ff980fa000 [ 334.825519] x23: ffffdbacb2e398ba x22: ffff07ff98102000 x21: ffff07ff981029c0 [ 334.832646] x20: 0000000000000001 x19: ffff07ff981029c0 x18: 0000000000000014 [ 334.839773] x17: 0000000000000000 x16: ffffdbacb1004364 x15: 0000aaaabe2f5a62 [ 334.846899] x14: ffff07ff8e55d968 x13: ffff07ff8e55db30 x12: 0000000000000000 [ 334.854026] x11: ffffdbacb21532e8 x10: 0000000000000001 x9 : ffffdbac857178ec [ 334.861153] x8 : ffff07ff9f6e5a28 x7 : 0000000000000000 x6 : 000000007c2b3742 [ 334.868279] x5 : ffff2c91ac905000 x4 : ffff2c91ac905000 x3 : ffff07ff9f554400 [ 334.875406] x2 : ffff2c91ac905000 x1 : 0000000000000001 x0 : ffff07ff981029c0 [ 334.882532] Call trace: [ 334.884967] bond_rr_gen_slave_id+0x40/0x124 [bonding] [ 334.890109] bond_xmit_roundrobin_slave_get+0x38/0xdc [bonding] [ 334.896033] __bond_start_xmit+0x128/0x3a0 [bonding] [ 334.901001] bond_start_xmit+0x54/0xb0 [bonding] [ 334.905622] dev_hard_start_xmit+0xb4/0x220 [ 334.909798] __dev_queue_xmit+0x1a0/0x720 [ 334.913799] arp_xmit+0x3c/0xbc [ 334.916932] arp_send_dst+0x98/0xd0 [ 334.920410] arp_solicit+0xe8/0x230 [ 334.923888] neigh_probe+0x60/0xb0 [ 334.927279] __neigh_event_send+0x3b0/0x470 [ 334.931453] neigh_resolve_output+0x70/0x90 [ 334.935626] ip_finish_output2+0x158/0x514 [ 334.939714] __ip_finish_output+0xac/0x1a4 [ 334.943800] ip_finish_output+0x40/0xfc [ 334.947626] ip_output+0xf8/0x1a4 [ 334.950931] ip_send_skb+0x5c/0x100 [ 334.954410] ip_push_pending_frames+0x3c/0x60 [ 334.958758] raw_sendmsg+0x458/0x6d0 [ 334.962325] inet_sendmsg+0x50/0x80 [ 334.965805] sock_sendmsg+0x60/0x6c [ 334.969286] __sys_sendto+0xc8/0x134 [ 334.972853] __arm64_sys_sendto+0x34/0x4c ---truncated--- | ||
| Risiko ? / 10 CVE-2022-48641 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix memory leak when blob is malformed The bug fix was incomplete, it "replaced" crash with a memory leak. The old code had an assignment to "ret" embedded into the conditional, restore this. | ||
| Risiko ? / 10 CVE-2022-48642 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix percpu memory leak at nf_tables_addchain() It seems to me that percpu memory for chain stats started leaking since commit 3bc158f8d0330f0a ("netfilter: nf_tables: map basechain priority to hardware priority") when nft_chain_offload_priority() returned an error. | ||
| Risiko ? / 10 CVE-2022-48635 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved:
fsdax: Fix infinite loop in dax_iomap_rw()
I got an infinite loop and a WARNING report when executing a tail command
in virtiofs.
WARNING: CPU: 10 PID: 964 at fs/iomap/iter.c:34 iomap_iter+0x3a2/0x3d0
Modules linked in:
CPU: 10 PID: 964 Comm: tail Not tainted 5.19.0-rc7
Call Trace:
|
||
| Risiko ? / 10 CVE-2022-48636 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved: s390/dasd: fix Oops in dasd_alias_get_start_dev due to missing pavgroup Fix Oops in dasd_alias_get_start_dev() function caused by the pavgroup pointer being NULL. The pavgroup pointer is checked on the entrance of the function but without the lcu->lock being held. Therefore there is a race window between dasd_alias_get_start_dev() and _lcu_update() which sets pavgroup to NULL with the lcu->lock held. Fix by checking the pavgroup pointer with lcu->lock held. | ||
| Risiko ? / 10 CVE-2022-48638 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved: cgroup: cgroup_get_from_id() must check the looked-up kn is a directory cgroup has to be one kernfs dir, otherwise kernel panic is caused, especially cgroup id is provide from userspace. | ||
| Risiko ? / 10 CVE-2022-48639 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved: net: sched: fix possible refcount leak in tc_new_tfilter() tfilter_put need to be called to put the refount got by tp->ops->get to avoid possible refcount leak when chain->tmplt_ops != NULL and chain->tmplt_ops != tp->ops. | ||
| Risiko ? / 10 CVE-2022-48634 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved:
drm/gma500: Fix BUG: sleeping function called from invalid context errors
gma_crtc_page_flip() was holding the event_lock spinlock while calling
crtc_funcs->mode_set_base() which takes ww_mutex.
The only reason to hold event_lock is to clear gma_crtc->page_flip_event
on mode_set_base() errors.
Instead unlock it after setting gma_crtc->page_flip_event and on
errors re-take the lock and clear gma_crtc->page_flip_event it
it is still set.
This fixes the following WARN/stacktrace:
[ 512.122953] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:870
[ 512.123004] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1253, name: gnome-shell
[ 512.123031] preempt_count: 1, expected: 0
[ 512.123048] RCU nest depth: 0, expected: 0
[ 512.123066] INFO: lockdep is turned off.
[ 512.123080] irq event stamp: 0
[ 512.123094] hardirqs last enabled at (0): [<0000000000000000>] 0x0
[ 512.123134] hardirqs last disabled at (0): [ |
||
| Risiko ? / 10 CVE-2022-48643 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix nft_counters_enabled underflow at nf_tables_addchain() syzbot is reporting underflow of nft_counters_enabled counter at nf_tables_addchain() [1], for commit 43eb8949cfdffa76 ("netfilter: nf_tables: do not leave chain stats enabled on error") missed that nf_tables_chain_destroy() after nft_basechain_init() in the error path of nf_tables_addchain() decrements the counter because nft_basechain_init() makes nft_is_base_chain() return true by setting NFT_CHAIN_BASE flag. Increment the counter immediately after returning from nft_basechain_init(). | ||
| Risiko ? / 10 CVE-2022-48644 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: avoid disabling offload when it was never enabled In an incredibly strange API design decision, qdisc->destroy() gets called even if qdisc->init() never succeeded, not exclusively since commit 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation"), but apparently also earlier (in the case of qdisc_create_dflt()). The taprio qdisc does not fully acknowledge this when it attempts full offload, because it starts off with q->flags = TAPRIO_FLAGS_INVALID in taprio_init(), then it replaces q->flags with TCA_TAPRIO_ATTR_FLAGS parsed from netlink (in taprio_change(), tail called from taprio_init()). But in taprio_destroy(), we call taprio_disable_offload(), and this determines what to do based on FULL_OFFLOAD_IS_ENABLED(q->flags). But looking at the implementation of FULL_OFFLOAD_IS_ENABLED() (a bitwise check of bit 1 in q->flags), it is invalid to call this macro on q->flags when it contains TAPRIO_FLAGS_INVALID, because that is set to U32_MAX, and therefore FULL_OFFLOAD_IS_ENABLED() will return true on an invalid set of flags. As a result, it is possible to crash the kernel if user space forces an error between setting q->flags = TAPRIO_FLAGS_INVALID, and the calling of taprio_enable_offload(). This is because drivers do not expect the offload to be disabled when it was never enabled. The error that we force here is to attach taprio as a non-root qdisc, but instead as child of an mqprio root qdisc: $ tc qdisc add dev swp0 root handle 1: \ mqprio num_tc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0 $ tc qdisc replace dev swp0 parent 1:1 \ taprio num_tc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \ sched-entry S 0x7f 990000 sched-entry S 0x80 100000 \ flags 0x0 clockid CLOCK_TAI Unable to handle kernel paging request at virtual address fffffffffffffff8 [fffffffffffffff8] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Call trace: taprio_dump+0x27c/0x310 vsc9959_port_setup_tc+0x1f4/0x460 felix_port_setup_tc+0x24/0x3c dsa_slave_setup_tc+0x54/0x27c taprio_disable_offload.isra.0+0x58/0xe0 taprio_destroy+0x80/0x104 qdisc_create+0x240/0x470 tc_modify_qdisc+0x1fc/0x6b0 rtnetlink_rcv_msg+0x12c/0x390 netlink_rcv_skb+0x5c/0x130 rtnetlink_rcv+0x1c/0x2c Fix this by keeping track of the operations we made, and undo the offload only if we actually did it. I've added "bool offloaded" inside a 4 byte hole between "int clockid" and "atomic64_t picos_per_byte". Now the first cache line looks like below: $ pahole -C taprio_sched net/sched/sch_taprio.o struct taprio_sched { struct Qdisc * * qdiscs; /* 0 8 */ struct Qdisc * root; /* 8 8 */ u32 flags; /* 16 4 */ enum tk_offsets tk_offset; /* 20 4 */ int clockid; /* 24 4 */ bool offloaded; /* 28 1 */ /* XXX 3 bytes hole, try to pack */ atomic64_t picos_per_byte; /* 32 0 */ /* XXX 8 bytes hole, try to pack */ spinlock_t current_entry_lock; /* 40 0 */ /* XXX 8 bytes hole, try to pack */ struct sched_entry * current_entry; /* 48 8 */ struct sched_gate_list * oper_sched; /* 56 8 */ /* --- cacheline 1 boundary (64 bytes) --- */ | ||
| Risiko ? / 10 CVE-2022-48645 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved: net: enetc: deny offload of tc-based TSN features on VF interfaces TSN features on the ENETC (taprio, cbs, gate, police) are configured through a mix of command BD ring messages and port registers: enetc_port_rd(), enetc_port_wr(). Port registers are a region of the ENETC memory map which are only accessible from the PCIe Physical Function. They are not accessible from the Virtual Functions. Moreover, attempting to access these registers crashes the kernel: $ echo 1 > /sys/bus/pci/devices/0000\:00\:00.0/sriov_numvfs pci 0000:00:01.0: [1957:ef00] type 00 class 0x020001 fsl_enetc_vf 0000:00:01.0: Adding to iommu group 15 fsl_enetc_vf 0000:00:01.0: enabling device (0000 -> 0002) fsl_enetc_vf 0000:00:01.0 eno0vf0: renamed from eth0 $ tc qdisc replace dev eno0vf0 root taprio num_tc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \ sched-entry S 0x7f 900000 sched-entry S 0x80 100000 flags 0x2 Unable to handle kernel paging request at virtual address ffff800009551a08 Internal error: Oops: 96000007 [#1] PREEMPT SMP pc : enetc_setup_tc_taprio+0x170/0x47c lr : enetc_setup_tc_taprio+0x16c/0x47c Call trace: enetc_setup_tc_taprio+0x170/0x47c enetc_setup_tc+0x38/0x2dc taprio_change+0x43c/0x970 taprio_init+0x188/0x1e0 qdisc_create+0x114/0x470 tc_modify_qdisc+0x1fc/0x6c0 rtnetlink_rcv_msg+0x12c/0x390 Split enetc_setup_tc() into separate functions for the PF and for the VF drivers. Also remove enetc_qos.o from being included into enetc-vf.ko, since it serves absolutely no purpose there. | ||
| Risiko ? / 10 CVE-2022-48646 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved: sfc/siena: fix null pointer dereference in efx_hard_start_xmit Like in previous patch for sfc, prevent potential (but unlikely) NULL pointer dereference. | ||
| Risiko ? / 10 CVE-2022-48647 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved:
sfc: fix TX channel offset when using legacy interrupts
In legacy interrupt mode the tx_channel_offset was hardcoded to 1, but
that's not correct if efx_sepparate_tx_channels is false. In that case,
the offset is 0 because the tx queues are in the single existing channel
at index 0, together with the rx queue.
Without this fix, as soon as you try to send any traffic, it tries to
get the tx queues from an uninitialized channel getting these errors:
WARNING: CPU: 1 PID: 0 at drivers/net/ethernet/sfc/tx.c:540 efx_hard_start_xmit+0x12e/0x170 [sfc]
[...]
RIP: 0010:efx_hard_start_xmit+0x12e/0x170 [sfc]
[...]
Call Trace:
|
||
| Risiko ? / 10 CVE-2022-48648 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved: sfc: fix null pointer dereference in efx_hard_start_xmit Trying to get the channel from the tx_queue variable here is wrong because we can only be here if tx_queue is NULL, so we shouldn't dereference it. As the above comment in the code says, this is very unlikely to happen, but it's wrong anyway so let's fix it. I hit this issue because of a different bug that caused tx_queue to be NULL. If that happens, this is the error message that we get here: BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [...] RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc] | ||
| Risiko ? / 10 CVE-2022-48649 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved:
mm/slab_common: fix possible double free of kmem_cache
When doing slub_debug test, kfence's 'test_memcache_typesafe_by_rcu'
kunit test case cause a use-after-free error:
BUG: KASAN: use-after-free in kobject_del+0x14/0x30
Read of size 8 at addr ffff888007679090 by task kunit_try_catch/261
CPU: 1 PID: 261 Comm: kunit_try_catch Tainted: G B N 6.0.0-rc5-next-20220916 #17
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
|
||
| Risiko ? / 10 CVE-2022-48650 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix memory leak in __qlt_24xx_handle_abts() Commit 8f394da36a36 ("scsi: qla2xxx: Drop TARGET_SCF_LOOKUP_LUN_FROM_TAG") made the __qlt_24xx_handle_abts() function return early if tcm_qla2xxx_find_cmd_by_tag() didn't find a command, but it missed to clean up the allocated memory for the management command. | ||
| Risiko ? / 10 CVE-2022-48651 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved: ipvlan: Fix out-of-bound bugs caused by unset skb->mac_header If an AF_PACKET socket is used to send packets through ipvlan and the default xmit function of the AF_PACKET socket is changed from dev_queue_xmit() to packet_direct_xmit() via setsockopt() with the option name of PACKET_QDISC_BYPASS, the skb->mac_header may not be reset and remains as the initial value of 65535, this may trigger slab-out-of-bounds bugs as following: ================================================================= UG: KASAN: slab-out-of-bounds in ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan] PU: 2 PID: 1768 Comm: raw_send Kdump: loaded Not tainted 6.0.0-rc4+ #6 ardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 all Trace: print_address_description.constprop.0+0x1d/0x160 print_report.cold+0x4f/0x112 kasan_report+0xa3/0x130 ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan] ipvlan_start_xmit+0x29/0xa0 [ipvlan] __dev_direct_xmit+0x2e2/0x380 packet_direct_xmit+0x22/0x60 packet_snd+0x7c9/0xc40 sock_sendmsg+0x9a/0xa0 __sys_sendto+0x18a/0x230 __x64_sys_sendto+0x74/0x90 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd The root cause is: 1. packet_snd() only reset skb->mac_header when sock->type is SOCK_RAW and skb->protocol is not specified as in packet_parse_headers() 2. packet_direct_xmit() doesn't reset skb->mac_header as dev_queue_xmit() In this case, skb->mac_header is 65535 when ipvlan_xmit_mode_l2() is called. So when ipvlan_xmit_mode_l2() gets mac header with eth_hdr() which use "skb->head + skb->mac_header", out-of-bound access occurs. This patch replaces eth_hdr() with skb_eth_hdr() in ipvlan_xmit_mode_l2() and reset mac header in multicast to solve this out-of-bound bug. | ||
| Risiko ? / 10 CVE-2022-48652 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved: ice: Fix crash by keep old cfg when update TCs more than queues There are problems if allocated queues less than Traffic Classes. Commit a632b2a4c920 ("ice: ethtool: Prohibit improper channel config for DCB") already disallow setting less queues than TCs. Another case is if we first set less queues, and later update more TCs config due to LLDP, ice_vsi_cfg_tc() will failed but left dirty num_txq/rxq and tc_cfg in vsi, that will cause invalid pointer access. [ 95.968089] ice 0000:3b:00.1: More TCs defined than queues/rings allocated. [ 95.968092] ice 0000:3b:00.1: Trying to use more Rx queues (8), than were allocated (1)! [ 95.968093] ice 0000:3b:00.1: Failed to config TC for VSI index: 0 [ 95.969621] general protection fault: 0000 [#1] SMP NOPTI [ 95.969705] CPU: 1 PID: 58405 Comm: lldpad Kdump: loaded Tainted: G U W O --------- -t - 4.18.0 #1 [ 95.969867] Hardware name: O.E.M/BC11SPSCB10, BIOS 8.23 12/30/2021 [ 95.969992] RIP: 0010:devm_kmalloc+0xa/0x60 [ 95.970052] Code: 5c ff ff ff 31 c0 5b 5d 41 5c c3 b8 f4 ff ff ff eb f4 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 89 d1 <8b> 97 60 02 00 00 48 8d 7e 18 48 39 f7 72 3f 55 89 ce 53 48 8b 4c [ 95.970344] RSP: 0018:ffffc9003f553888 EFLAGS: 00010206 [ 95.970425] RAX: dead000000000200 RBX: ffffea003c425b00 RCX: 00000000006080c0 [ 95.970536] RDX: 00000000006080c0 RSI: 0000000000000200 RDI: dead000000000200 [ 95.970648] RBP: dead000000000200 R08: 00000000000463c0 R09: ffff888ffa900000 [ 95.970760] R10: 0000000000000000 R11: 0000000000000002 R12: ffff888ff6b40100 [ 95.970870] R13: ffff888ff6a55018 R14: 0000000000000000 R15: ffff888ff6a55460 [ 95.970981] FS: 00007f51b7d24700(0000) GS:ffff88903ee80000(0000) knlGS:0000000000000000 [ 95.971108] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 95.971197] CR2: 00007fac5410d710 CR3: 0000000f2c1de002 CR4: 00000000007606e0 [ 95.971309] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 95.971419] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 95.971530] PKRU: 55555554 [ 95.971573] Call Trace: [ 95.971622] ice_setup_rx_ring+0x39/0x110 [ice] [ 95.971695] ice_vsi_setup_rx_rings+0x54/0x90 [ice] [ 95.971774] ice_vsi_open+0x25/0x120 [ice] [ 95.971843] ice_open_internal+0xb8/0x1f0 [ice] [ 95.971919] ice_ena_vsi+0x4f/0xd0 [ice] [ 95.971987] ice_dcb_ena_dis_vsi.constprop.5+0x29/0x90 [ice] [ 95.972082] ice_pf_dcb_cfg+0x29a/0x380 [ice] [ 95.972154] ice_dcbnl_setets+0x174/0x1b0 [ice] [ 95.972220] dcbnl_ieee_set+0x89/0x230 [ 95.972279] ? dcbnl_ieee_del+0x150/0x150 [ 95.972341] dcb_doit+0x124/0x1b0 [ 95.972392] rtnetlink_rcv_msg+0x243/0x2f0 [ 95.972457] ? dcb_doit+0x14d/0x1b0 [ 95.972510] ? __kmalloc_node_track_caller+0x1d3/0x280 [ 95.972591] ? rtnl_calcit.isra.31+0x100/0x100 [ 95.972661] netlink_rcv_skb+0xcf/0xf0 [ 95.972720] netlink_unicast+0x16d/0x220 [ 95.972781] netlink_sendmsg+0x2ba/0x3a0 [ 95.975891] sock_sendmsg+0x4c/0x50 [ 95.979032] ___sys_sendmsg+0x2e4/0x300 [ 95.982147] ? kmem_cache_alloc+0x13e/0x190 [ 95.985242] ? __wake_up_common_lock+0x79/0x90 [ 95.988338] ? __check_object_size+0xac/0x1b0 [ 95.991440] ? _copy_to_user+0x22/0x30 [ 95.994539] ? move_addr_to_user+0xbb/0xd0 [ 95.997619] ? __sys_sendmsg+0x53/0x80 [ 96.000664] __sys_sendmsg+0x53/0x80 [ 96.003747] do_syscall_64+0x5b/0x1d0 [ 96.006862] entry_SYSCALL_64_after_hwframe+0x65/0xca Only update num_txq/rxq when passed check, and restore tc_cfg if setup queue map failed. | ||
| Risiko ? / 10 CVE-2022-48653 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved:
ice: Don't double unplug aux on peer initiated reset
In the IDC callback that is accessed when the aux drivers request a reset,
the function to unplug the aux devices is called. This function is also
called in the ice_prepare_for_reset function. This double call is causing
a "scheduling while atomic" BUG.
[ 662.676430] ice 0000:4c:00.0 rocep76s0: cqp opcode = 0x1 maj_err_code = 0xffff min_err_code = 0x8003
[ 662.676609] ice 0000:4c:00.0 rocep76s0: [Modify QP Cmd Error][op_code=8] status=-29 waiting=1 completion_err=1 maj=0xffff min=0x8003
[ 662.815006] ice 0000:4c:00.0 rocep76s0: ICE OICR event notification: oicr = 0x10000003
[ 662.815014] ice 0000:4c:00.0 rocep76s0: critical PE Error, GLPE_CRITERR=0x00011424
[ 662.815017] ice 0000:4c:00.0 rocep76s0: Requesting a reset
[ 662.815475] BUG: scheduling while atomic: swapper/37/0/0x00010002
[ 662.815475] BUG: scheduling while atomic: swapper/37/0/0x00010002
[ 662.815477] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs rfkill 8021q garp mrp stp llc vfat fat rpcrdma intel_rapl_msr intel_rapl_common sunrpc i10nm_edac rdma_ucm nfit ib_srpt libnvdimm ib_isert iscsi_target_mod x86_pkg_temp_thermal intel_powerclamp coretemp target_core_mod snd_hda_intel ib_iser snd_intel_dspcfg libiscsi snd_intel_sdw_acpi scsi_transport_iscsi kvm_intel iTCO_wdt rdma_cm snd_hda_codec kvm iw_cm ipmi_ssif iTCO_vendor_support snd_hda_core irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hwdep snd_seq snd_seq_device rapl snd_pcm snd_timer isst_if_mbox_pci pcspkr isst_if_mmio irdma intel_uncore idxd acpi_ipmi joydev isst_if_common snd mei_me idxd_bus ipmi_si soundcore i2c_i801 mei ipmi_devintf i2c_smbus i2c_ismt ipmi_msghandler acpi_power_meter acpi_pad rv(OE) ib_uverbs ib_cm ib_core xfs libcrc32c ast i2c_algo_bit drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm_ttm_helpe
r ttm
[ 662.815546] nvme nvme_core ice drm crc32c_intel i40e t10_pi wmi pinctrl_emmitsburg dm_mirror dm_region_hash dm_log dm_mod fuse
[ 662.815557] Preemption disabled at:
[ 662.815558] [<0000000000000000>] 0x0
[ 662.815563] CPU: 37 PID: 0 Comm: swapper/37 Kdump: loaded Tainted: G S OE 5.17.1 #2
[ 662.815566] Hardware name: Intel Corporation D50DNP/D50DNP, BIOS SE5C6301.86B.6624.D18.2111021741 11/02/2021
[ 662.815568] Call Trace:
[ 662.815572] |
||
| Risiko ? / 10 CVE-2022-48654 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_osf: fix possible bogus match in nf_osf_find() nf_osf_find() incorrectly returns true on mismatch, this leads to copying uninitialized memory area in nft_osf which can be used to leak stale kernel stack data to userspace. | ||
| Risiko ? / 10 CVE-2022-48655 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Harden accesses to the reset domains Accessing reset domains descriptors by the index upon the SCMI drivers requests through the SCMI reset operations interface can potentially lead to out-of-bound violations if the SCMI driver misbehave. Add an internal consistency check before any such domains descriptors accesses. | ||
| Risiko ? / 10 CVE-2022-48656 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: k3-udma-private: Fix refcount leak bug in of_xudma_dev_get() We should call of_node_put() for the reference returned by of_parse_phandle() in fail path or when it is not used anymore. Here we only need to move the of_node_put() before the check. | ||
| Risiko ? / 10 CVE-2022-48657 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved: arm64: topology: fix possible overflow in amu_fie_setup() cpufreq_get_hw_max_freq() returns max frequency in kHz as *unsigned int*, while freq_inv_set_max_ratio() gets passed this frequency in Hz as 'u64'. Multiplying max frequency by 1000 can potentially result in overflow -- multiplying by 1000ULL instead should avoid that... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. | ||
| Risiko ? / 10 CVE-2022-48658 | vor 12 Stunde(n) | |
| In the Linux kernel, the following vulnerability has been resolved: mm: slub: fix flush_cpu_slab()/__free_slab() invocations in task context. Commit 5a836bf6b09f ("mm: slub: move flush_cpu_slab() invocations __free_slab() invocations out of IRQ context") moved all flush_cpu_slab() invocations to the global workqueue to avoid a problem related with deactivate_slab()/__free_slab() being called from an IRQ context on PREEMPT_RT kernels. When the flush_all_cpu_locked() function is called from a task context it may happen that a workqueue with WQ_MEM_RECLAIM bit set ends up flushing the global workqueue, this will cause a dependency issue. workqueue: WQ_MEM_RECLAIM nvme-delete-wq:nvme_delete_ctrl_work [nvme_core] is flushing !WQ_MEM_RECLAIM events:flush_cpu_slab WARNING: CPU: 37 PID: 410 at kernel/workqueue.c:2637 check_flush_dependency+0x10a/0x120 Workqueue: nvme-delete-wq nvme_delete_ctrl_work [nvme_core] RIP: 0010:check_flush_dependency+0x10a/0x120[ 453.262125] Call Trace: __flush_work.isra.0+0xbf/0x220 ? __queue_work+0x1dc/0x420 flush_all_cpus_locked+0xfb/0x120 __kmem_cache_shutdown+0x2b/0x320 kmem_cache_destroy+0x49/0x100 bioset_exit+0x143/0x190 blk_release_queue+0xb9/0x100 kobject_cleanup+0x37/0x130 nvme_fc_ctrl_free+0xc6/0x150 [nvme_fc] nvme_free_ctrl+0x1ac/0x2b0 [nvme_core] Fix this bug by creating a workqueue for the flush operation with the WQ_MEM_RECLAIM bit set. | ||
| 24.04.2024 - Piping Rock | 2.103.100 Datensätze geleaked | |
| Email addresses, Names, Phone numbers, Physical addresses In April 2024, 2.1M email addresses from the online health products store Piping Rock were publicly posted to a popular hacking forum. The data also included names, phone numbers and physical addresses. The account posting the data had previously posted multiple other data breaches which all appear to have been obtained from the Shopify service used by the respective websites. |
||
| 17.04.2024 - T2 | 94.584 Datensätze geleaked | |
| Dates of birth, Email addresses, Names, Passwords, Phone numbers, Physical addresses, Purchases, Salutations In April 2024, 95k records from the T2 tea store were posted to a popular hacking forum. Data included email and physical addresses, names, phone numbers, dates of birth, purchases and passwords stored as scrypt hashes. |
||
| 13.04.2024 - Le Slip Français | 1.495.127 Datensätze geleaked | |
| Email addresses, Names, Phone numbers, Physical addresses In April 2024, the French underwear maker Le Slip Français suffered a data breach. The breach included 1.5M email addresses, physical addresses, names and phone numbers. |
||
| 02.04.2024 - Salvadoran Citizens | 946.989 Datensätze geleaked | |
| Dates of birth, Email addresses, Government issued IDs, Names, Phone numbers, Physical addresses, Profile photos In April 2024, nearly 6 million records of Salvadoran citizens were published to a popular hacking forum. The data included names, dates of birth, phone numbers, physical addresses and nearly 1M unique email addresses. Further, over 5M corresponding profile photos were also included in the breach. |
||
| 31.03.2024 - Pandabuy | 1.348.407 Datensätze geleaked | |
| Email addresses, IP addresses, Names, Phone numbers, Physical addresses In March 2024, 1.3M unique email addresses from the online store for purchasing goods from China, Pandabuy, were posted to a popular hacking forum. The data also included IP and physical addresses, names, phone numbers and order enquiries. The breach was alleged to be attributed to "Sanggiero" and "IntelBroker". |
||
| 25.03.2024 - boAt | 7.528.985 Datensätze geleaked | |
| Email addresses, Names, Phone numbers, Physical addresses In March 2024, the Indian audio and wearables brand boAt suffered a data breach that exposed 7.5M customer records. The data included physical and email address, names and phone numbers, all of which were subsequently published to a popular clear web hacking forum. |
||
| 24.03.2024 - Kaspersky Club | 55.971 Datensätze geleaked | |
| Email addresses, IP addresses, Passwords, Usernames In March 2024, the independent fan forum Kaspersky Club suffered a data breach. The incident exposed 56k unique email addresses alongside usernames, IP addresses and passwords stored as either MD5 or bcrypt hashes. |
||
| 23.03.2024 - England Cricket | 43.299 Datensätze geleaked | |
| Email addresses, Passwords In March 2024, English Cricket's icoachcricket website suffered a data breach that exposed over 40k records. The data included email addresses and passwords stored as either bcrypt hashes, salted MD5 hashes or both. The data was provided to HIBP by a source who requested it be attributed to "IntelBroker". |
||
| 04.03.2024 - Giant Tiger | 2.842.669 Datensätze geleaked | |
| Email addresses, Names, Phone numbers, Physical addresses In March 2024, Canadian discount store Giant Tiger suffered a data breach that exposed 2.8M customer records. Attributed to a vendor of the retailer, the breach included physical and email addresses, names and phone numbers. |
||
| 03.03.2024 - WoTLabs | 21.994 Datensätze geleaked | |
| Dates of birth, Email addresses, IP addresses, Time zones, Usernames In March 2024, WoTLabs (World of Tanks Statistics and Resources) suffered a data breach and website defacement attributed to "chromebook breachers". The breach exposed 22k forum members' personal data including email and IP addresses, usernames, dates of birth and time zones. |
||
| 01.03.2024 - Mr. Green Gaming | 27.123 Datensätze geleaked | |
| Dates of birth, Email addresses, Geographic locations, IP addresses, Usernames In March 2024, the online games community Mr. Green Gaming suffered a data breach that exposed 27k user records. Acknowledged on their Discord server, the incident exposed email and IP addresses, usernames, geographic locations and dates of birth. |
||
| 26.02.2024 - Cutout.Pro | 19.972.829 Datensätze geleaked | |
| Email addresses, IP addresses, Names, Passwords In February 2024, the AI-powered visual design platform Cutout.Pro suffered a data breach that exposed 20M records. The data included email and IP addresses, names and salted MD5 password hashes which were subsequently broadly distributed on a popular hacking forum and Telegram channels. |
||
| 18.02.2024 - Tangerine | 243.462 Datensätze geleaked | |
| Dates of birth, Email addresses, Names, Passwords, Phone numbers, Physical addresses, Salutations In February 2024, the Australian Telco Tangerine suffered a data breach that exposed over 200k customer records. Attributed to a legacy customer database, the data included physical and email addresses, names, phone numbers and dates of birth. Whilst the Tangerine login process involves sending a one-time password after entering an email address and phone number, it previously used a traditional password which was also exposed as a bcrypt hash. |
||
| 01.02.2024 - SurveyLama | 4.426.879 Datensätze geleaked | |
| Dates of birth, Email addresses, IP addresses, Names, Passwords, Phone numbers, Physical addresses In February 2024, the paid survey website SurveyLama suffered a data breach that exposed 4.4M customer email addresses. The incident also exposed names, physical and IP addresses, phone numbers, dates of birth and passwords stored as either salted SHA-1, bcrypt or argon2 hashes. When contacted about the incident, SurveyLama advised that they had already "notified the users by email". |
||
| 31.01.2024 - Spoutible | 207.114 Datensätze geleaked | |
| Email addresses, Genders, IP addresses, Names, Passwords, Phone numbers, Usernames In January 2024, Spoutible had 207k records scraped from a misconfigured API that inadvertently returned excessive personal information. The data included names, usernames, email and IP addresses, phone numbers (where provided to the platform), genders and bcrypt password hashes. The incident also exposed 2FA secrets and backup codes along with password reset tokens. |
||
| 16.01.2024 - Trello | 15.111.945 Datensätze geleaked | |
| Email addresses, Names, Usernames In January 2024, data was scraped from Trello and posted for sale on a popular hacking forum. Containing over 15M email addresses, names and usernames, the data was obtained by enumerating a publicly accessible resource using email addresses from previous breach corpuses. Trello advised that no unauthorised access had occurred. |
||
| 17.12.2023 - Hathway | 4.670.080 Datensätze geleaked | |
| Device information, Email addresses, IP addresses, Names, Passwords, Phone numbers, Physical addresses, Salutations, Support tickets In December 2023, hundreds of gigabytes of data allegedly taken from Indian ISP and digital TV provider Hathway appeared on a popular hacking website. The incident exposed extensive personal information including 4.7M unique email addresses along with names, physical and IP addresses, phone numbers, password hashes and support ticket logs. |
||
| 12.12.2023 - InflateVids | 13.405 Datensätze geleaked | |
| Email addresses, Genders, IP addresses, Passwords, Usernames In December 2023, the inflatable and balloon fetish videos website InflateVids suffered a data breach. The incident exposed over 13k unique email addresses alongside usernames, IP addresses, genders and SHA-1 password hashes. |
||
| 14.11.2023 - KitchenPal | 98.726 Datensätze geleaked | |
| Dates of birth, Email addresses, Genders, Geographic locations, Names, Passwords, Physical attributes, Social media profiles In November 2023, the kitchen management application KitchenPal suffered a data breach that exposed 146k lines of data. When contacted about the incident, KitchenPal advised the corpus of data came from a staging environment, although acknowledged it contained a small number of users for debugging purposes and included passwords that could not be used. Impacted data included almost 100k email addresses, names, geolocations and incomplete data on dates of birth, genders, height and weight, social media profile identifiers and bcrypt password hashes. |
||
| 08.11.2023 - Chess | 827.620 Datensätze geleaked | |
| Email addresses, Geographic locations, Names, Usernames In November 2023, over 800k user records were scraped from the Chess website and posted to a popular hacking forum. The data included email address, name, username and the geographic location of the user. |
||
| 04.11.2023 - LinkedIn Scraped and Faked Data (2023) | 19.788.753 Datensätze geleaked | |
| Email addresses, Genders, Geographic locations, Job titles, Names, Professional skills, Social media profiles In November 2023, a post to a popular hacking forum alleged that millions of LinkedIn records had been scraped and leaked. On investigation, the data turned out to be a combination of legitimate data scraped from LinkedIn and email addresses constructed from impacted individuals' names. |
||
| 18.10.2023 - Toumei | 76.682 Datensätze geleaked | |
| Email addresses, Names, Phone numbers, Physical addresses In October 2023, the Japanese consultancy firm Toumei suffered a data breach. The breach exposed over 100M lines and 10GB of data including 77k unique email addresses along with names, phone numbers and physical addresses. |
||
| 01.10.2023 - Facebook Marketplace | 77.267 Datensätze geleaked | |
| Email addresses, Geographic locations, Names, Passwords, Phone numbers, Social media profiles In February 2024, 200k Facebook Marketplace records allegedly obtained from a Meta contractor in October 2023 were posted to a popular hacking forum. The data contained 77k unique email addresses alongside names, phone numbers, Facebook profile IDs and geographic locations. The data also contained bcrypt password hashes, although there is no indication these belong to the corresponding Facebook accounts. |
||
| 20.09.2023 - Naz.API | 70.840.771 Datensätze geleaked | |
| Email addresses, Passwords In September 2023, over 100GB of stealer logs and credential stuffing lists titled "Naz.API" was posted to a popular hacking forum. The incident contained a combination of email address and plain text password pairs alongside the service they were entered into, and standalone credential pairs obtained from unnamed sources. In total, the corpus of data included 71M unique email addresses and 100M unique passwords. |
||
| 09.09.2023 - Sphero | 832.255 Datensätze geleaked | |
| Dates of birth, Email addresses, Geographic locations, Names, Usernames In September 2023, over 1M rows of data from the educational robots company Sphero was posted to a popular hacking forum. The data contained 832k unique email addresses alongside names, usernames, dates of birth and geographic locations. |
||
| 29.08.2023 - Qakbot | 6.431.319 Datensätze geleaked | |
| Email addresses, Passwords In August 2023, the US Justice Department announced a multinational operation involving actions in the United States, France, Germany, the Netherlands, and the United Kingdom to disrupt the botnet and malware known as Qakbot and take down its infrastructure. After the takedown, 6.43M email addresses were provided to HIBP to help notify victims of the malware. |
||
| 09.08.2023 - PlayCyberGames | 3.681.753 Datensätze geleaked | |
| Email addresses, Passwords, Usernames In August 2023, PlayCyberGames which "allows users to play any games with LAN function or games using IP address" suffered a data breach which exposed 3.7M customer records. The data included email addresses, usernames and MD5 password hashes with a constant value in the "salt" field. PlayCyberGames did not respond to multiple attempts to disclose the breach. |
||
| 02.08.2023 - MagicDuel | 138.443 Datensätze geleaked | |
| Email addresses, IP addresses, Nicknames, Passwords In August 2023, the MagicDuel Adventure website suffered a data breach that exposed 138k user records. The data included player names, email and IP addresses and bcrypt password hashes. |
||
| 16.07.2023 - Manipulated Caiman | 39.901.389 Datensätze geleaked | |
| Email addresses In July 2023, Perception Point reported on a phishing operation dubbed "Manipulated Caiman". Targeting primarily the citizens of Mexico, the campaign attempted to gain access to victims' bank accounts via spear phishing attacks using malicious attachments. Researchers obtained almost 40M email addresses targeted in the campaign and provided the data to HIBP to alert potential victims. |
||
| 09.07.2023 - Rightbiz | 65.376 Datensätze geleaked | |
| Email addresses, Names, Phone numbers, Physical addresses In June 2023, data belonging to the "UK's No.1 Business Marketplace" Rightbiz appeared on a popular hacking forum. Comprising of more than 18M rows of data, the breach included 65k unique email addresses along with names, phone numbers and physical address. Rightbiz didn't respond to mulitple attempts to disclose the incident. The data was provided to HIBP by a source who requested it be attributed to "https://discord.gg/gN9C9em". |
||
| 20.06.2023 - Dymocks | 836.120 Datensätze geleaked | |
| Dates of birth, Email addresses, Genders, Names, Phone numbers, Physical addresses In September 2023, the Australian book retailer Dymocks announced a data breach. The data dated back to June 2023 and contained 1.2M records with 836k unique email addresses. The breach also exposed names, dates of birth, genders, phone numbers and physical addresses. |
||
| 17.06.2023 - BreachForums Clone | 4.204 Datensätze geleaked | |
| Email addresses, IP addresses, Passwords, Usernames In June 2023, a clone of the previously shuttered popular hacking forum "BreachForums" suffered a data breach that exposed over 4k records. The breach was due to an exposed backup of the MyBB database which included email and IP addresses, usernames and Argon2 password hashes. |
||
| 31.05.2023 - JD Group | 521.878 Datensätze geleaked | |
| Email addresses, Government issued IDs, Names, Phone numbers, Physical addresses In May 2023, the South African retailer JD Group announced a data breach affecting a number of their online assets including Bradlows, Everyshop, HiFi Corp, Incredible (Connection), Rochester, Russells, and Sleepmasters. The breach exposed over 520k unique customer records including names, email and physical addresses, phone numbers and South African ID numbers. |
||
| 29.05.2023 - Polish Credentials | 1.204.870 Datensätze geleaked | |
| Email addresses, Passwords In May 2023, a credential stuffing list of 6.3M Polish email address and password pairs appeared on a local forum. Likely obtained by malware running on victims' machines, each record included an email address and plain text password alongside the website the credentials were used on. The data included 1.2M unique email addresses. |
||
| 15.04.2023 - Jobzone | 29.708 Datensätze geleaked | |
| Dates of birth, Email addresses, Family members' names, Genders, Government issued IDs, Names, Phone numbers, Physical addresses In April 2023, data from the Israeli jobs website Jobzone was posted online. The data included 30k records of email addresses, names, social security numbers, genders, dates of birth, fathers' names and physical addresses. |
||
| 15.04.2023 - RentoMojo | 2.185.697 Datensätze geleaked | |
| Dates of birth, Email addresses, Genders, Government issued IDs, Names, Passport numbers, Passwords, Phone numbers, Purchases, Social media profiles In April 2023, the Indian rental service RentoMojo suffered a data breach. The breach exposed over 2M unique email addresses along with names, phone, passport and Aadhaar numbers, genders, dates of birth, purchases and bcrypt password hashes. |
||
| 05.04.2023 - Genesis Market | 8.000.000 Datensätze geleaked | |
| Browser user agent details, Credit card CVV, Credit cards, Dates of birth, Email addresses, Names, Passwords, Phone numbers, Physical addresses, Usernames In April 2023, the stolen identity marketplace Genesis Market was shut down by the FBI and a coalition of law enforcement agencies across the globe in "Operation Cookie Monster". The service traded in "browser fingerprints" which enabled criminals to impersonate victims and access their online services. As many of the impacted accounts did not include email addresses, "8M" is merely an approximation intended to indicate scale. Other personal data compromised by the service included names, addresses and credit card information, although not all individuals had each of these fields exposed. |
||
| 31.03.2023 - Tigo | 700.394 Datensätze geleaked | |
| Device information, Email addresses, Genders, Geographic locations, IP addresses, Names, Private messages, Profile photos, Usernames In Mid-2023, 300GB of data containing over 100M records from the Chinese video chat platform "Tigo" dating back to March that year was discovered. The data contained over 700k unique names, usernames, email and IP addresses, genders, profile photos and private messages. Tigo did not respond to multiple attempts to disclose the incident. |
||
| 15.03.2023 - MediaWorks | 162.710 Datensätze geleaked | |
| Dates of birth, Email addresses, Genders, Phone numbers, Physical addresses In March 2024, millions of rows of data from the New Zealand media company MediaWorks was publicly posted to a popular hacking forum. The incident exposed 163k unique email addresses provided by visitors who filled out online competitions and included names, physical addresses, phone numbers, dates of birth, genders and the responses to questions in the competition. Some victims of the breach subsequently received ransom demands requesting payment to have their data deleted. |
||
| 06.03.2023 - DC Health Link | 48.145 Datensätze geleaked | |
| Citizenship statuses, Dates of birth, Email addresses, Employers, Ethnicities, Genders, Names, Phone numbers, Physical addresses, Purchases, Social security numbers In March 2023, DC Health Link discovered a data breach that was later publicly posted to a popular data breach forum. The impacted data included 48k unique email addresses alongside names, genders, dates of birth, home addresses, phone numbers and social security numbers. The data was provided to HIBP by a source who requested it be attributed to "Aegis" and "IntelBroker". |
||