Page 117 of 1286 results (0.009 seconds)

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: jfs: fix null ptr deref in dtInsertEntry [syzbot reported] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 5061 Comm: syz-executor404 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:dtInsertEntry+0xd0c/0x1780 fs/jfs/jfs_dtree.c:3713 ... [Analyze] In dtInsertEntry(), when the pointer h has the same value as p, after writing name in UniStrncpy_to_le(), p->header.flag will be cleared. This will cause the previously true judgment "p->header.flag & BT-LEAF" to change to no after writing the name operation, this leads to entering an incorrect branch and accessing the uninitialized object ih when judging this condition for the second time. [Fix] After got the page, check freelist first, if freelist == 0 then exit dtInsert() and return -EINVAL. • https://git.kernel.org/stable/c/53023ab11836ac56fd75f7a71ec1356e50920fa9 https://git.kernel.org/stable/c/6ea10dbb1e6c58384136e9adfd75f81951e423f6 https://git.kernel.org/stable/c/9c2ac38530d1a3ee558834dfa16c85a40fd0e702 https://git.kernel.org/stable/c/ce6dede912f064a855acf6f04a04cbb2c25b8c8c •

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: jfs: Fix shift-out-of-bounds in dbDiscardAG When searching for the next smaller log2 block, BLKSTOL2() returned 0, causing shift exponent -1 to be negative. This patch fixes the issue by exiting the loop directly when negative shift is found. • https://git.kernel.org/stable/c/bd04a149e3a29e7f71b7956ed41dba34e42d539e https://git.kernel.org/stable/c/f650148b43949ca9e37e820804bb6026fff404f3 https://git.kernel.org/stable/c/234e6ea0855cdb5673d54ecaf7dc5c78f3e84630 https://git.kernel.org/stable/c/7063b80268e2593e58bee8a8d709c2f3ff93e2f2 •

CVSS: -EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel-vbtn: Protect ACPI notify handler against recursion Since commit e2ffcda16290 ("ACPI: OSL: Allow Notify () handlers to run on all CPUs") ACPI notify handlers like the intel-vbtn notify_handler() may run on multiple CPU cores racing with themselves. This race gets hit on Dell Venue 7140 tablets when undocking from the keyboard, causing the handler to try and register priv->switches_dev twice, as can be seen from the dev_info() message getting logged twice: [ 83.861800] intel-vbtn INT33D6:00: Registering Intel Virtual Switches input-dev after receiving a switch event [ 83.861858] input: Intel Virtual Switches as /devices/pci0000:00/0000:00:1f.0/PNP0C09:00/INT33D6:00/input/input17 [ 83.861865] intel-vbtn INT33D6:00: Registering Intel Virtual Switches input-dev after receiving a switch event After which things go seriously wrong: [ 83.861872] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:1f.0/PNP0C09:00/INT33D6:00/input/input17' ... [ 83.861967] kobject: kobject_add_internal failed for input17 with -EEXIST, don't try to register things with the same name in the same directory. [ 83.877338] BUG: kernel NULL pointer dereference, address: 0000000000000018 ... Protect intel-vbtn notify_handler() from racing with itself with a mutex to fix this. • https://git.kernel.org/stable/c/e2ffcda1629012a2c1a3706432bc45fdc899a584 https://git.kernel.org/stable/c/5c9618a3b6ea94cf7bdff7702aca8bf2d777d97b https://git.kernel.org/stable/c/e075c3b13a0a142dcd3151b25d29a24f31b7b640 •

CVSS: -EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: power: supply: rt5033: Bring back i2c_set_clientdata Commit 3a93da231c12 ("power: supply: rt5033: Use devm_power_supply_register() helper") reworked the driver to use devm. While at it, the i2c_set_clientdata was dropped along with the remove callback. Unfortunately other parts of the driver also rely on i2c clientdata so this causes kernel oops. Bring the call back to fix the driver. • https://git.kernel.org/stable/c/3a93da231c12bb153224bbbdd3d9a83da9e0ba33 https://git.kernel.org/stable/c/3c5d0871b0af0184abc6f7f52f8705b39a6251ae https://git.kernel.org/stable/c/d3911f1639e67fc7b12aae0efa5a540976d7443b •

CVSS: -EPSS: 0%CPEs: 7EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: sctp: Fix null-ptr-deref in reuseport_add_sock(). syzbot reported a null-ptr-deref while accessing sk2->sk_reuseport_cb in reuseport_add_sock(). [0] The repro first creates a listener with SO_REUSEPORT. Then, it creates another listener on the same port and concurrently closes the first listener. The second listen() calls reuseport_add_sock() with the first listener as sk2, where sk2->sk_reuseport_cb is not expected to be cleared concurrently, but the close() does clear it by reuseport_detach_sock(). The problem is SCTP does not properly synchronise reuseport_alloc(), reuseport_add_sock(), and reuseport_detach_sock(). The caller of reuseport_alloc() and reuseport_{add,detach}_sock() must provide synchronisation for sockets that are classified into the same reuseport group. Otherwise, such sockets form multiple identical reuseport groups, and all groups except one would be silently dead. 1. Two sockets call listen() concurrently 2. No socket in the same group found in sctp_ep_hashtable[] 3. Two sockets call reuseport_alloc() and form two reuseport groups 4. • https://git.kernel.org/stable/c/6ba84574026792ce33a40c7da721dea36d0f3973 https://git.kernel.org/stable/c/c9b3fc4f157867e858734e31022ebee8a24f0de7 https://git.kernel.org/stable/c/52319d9d2f522ed939af31af70f8c3a0f0f67e6c https://git.kernel.org/stable/c/54b303d8f9702b8ab618c5032fae886b16356928 https://git.kernel.org/stable/c/05e4a0fa248240efd99a539853e844f0f0a9e6a5 https://git.kernel.org/stable/c/1407be30fc17eff918a98e0a990c0e988f11dc84 https://git.kernel.org/stable/c/e809a84c802377ef61525a298a1ec1728759b913 https://git.kernel.org/stable/c/9ab0faa7f9ffe31296dbb9bbe6f76c72c •